> For the complete documentation index, see [llms.txt](https://docs.riff.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.riff.ai/interactive-guides/how-to-add-api-access-to-an-application.md). # How to add API access to an application {% @riff-academy/riff-academy-guide url="" %} ### What an API is, and what a key is An API is a way for one piece of software to ask another one questions and get answers. It returns the same information a colleague could look up and send you, without the colleague. A CRM, a finance system, a helpdesk, a scheduling tool — this is how each of them lets other software in. A key is the password for that conversation. It is issued to software rather than to a person, so the system can tell your app is allowed to ask. Whoever runs that system creates it; Riff cannot, and neither can the agent. ### Start from a file export Getting a key involves other people: whoever owns the system has to agree, issue it, and decide what it may reach. That takes as long as it takes. Do not wait for it. Most business systems will export their data — a CSV or a spreadsheet, from a button in the interface — and that needs nothing beyond the access somebody already has. Ask for one, and have the agent build on it. This is a normal way to begin, not a fallback. You get something people can use while access is being arranged, and you find out whether the app is right before anyone grants it. By the time you connect the live system you will have seen the real data, which is what tells you whether the connection is returning the right thing. ### Find out if your system has an API You may not know whether the system you need has an API at all, or whether your company's copy of it can be reached from outside. You do not have to work that out yourself. Give the agent the system and a link to its documentation and ask. It comes back with whether there is one, what it needs, and who you have to ask for it. Four things make the request work. What you want. A link to the system's documentation, so it reads rather than guesses. Who you are — not technical. And what you want back: the steps, in order, with the ones that are yours marked as yours. > I want to connect \[system] to this app using its API. > \ > Research this system — \[link to its documentation] — and identify the steps I need to take. > \ > I am not technical, so walk me through it one step at a time. Tell me exactly what I need to get, and who to ask for it, and what you will do here. ### The key does not go in the chat A key is a long line of letters and numbers, and it does not go in the chat. The chat is a transcript. Anything typed into it stays in it, and can be read by anyone who can open the app later. The agent will not take a key here — it names the secret it wants and leaves you to store it. Click below to learn how to add API secrets to your application. {% content-ref url="/pages/OwUQjtCofyzOSbsKJBUa" %} [Secrets](/reference/shared/secrets.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.riff.ai/interactive-guides/how-to-add-api-access-to-an-application.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.