See how to add custom APIs and functionality to the Stevesie platform.
Once you find an API you'd like to scrape data from, you can always do it yourself using your own software - or if you'd prefer to save a lot of time and headache, you can add the integration to the Stevesie platform.
Everything on the Stevesie platform is organized into "apps" which represent different API endpoints you can use to access a common source. Most of the time, we can deem "apps" and third party "APIs" as being the same thing.
Each app has a set of maintainers on the Stevesie platform, who are responsible for curating and updating the integrations listed on each app. If you're just looking to use other people's contributions, then you don't need to worry too much about this yet.
You can browse and search for the currently supported apps on the Stevesie App Directory. If you can't find an app, then you can create a new app at any time with a Stevesie account.
You simply need to pick a unique name for the app and provide a link to the website and domain name of where most of the API endpoints will point to.
If the API you want to scrape data from is already listed in the app directory, you can simply add a new endpoint to it if the functionality you need is not already listed. You can share your integration publicly if you'd like (so it shows up on the app's page) if the app maintainers approve your content. We'll discuss more on adding new endpoints below.
Each app contains multiple endpoints in it, which typically are all just different API endpoints pointing to the same data source. If you need to add additional endpoints to an app (either one that you create or someone else maintains), it's very simple!
You can always create a new endpiont from scratch, entering in all the request details as needed. If you're building a new app, this will be your only option when adding its first endpoint.
Once you create an initial endpoint (or find a similar endpoint from another user), you may find it easier to just "clone" the endpoint into a new one and make your edits there. Just navigate to the endpoint you'd like to clone and select the black arrow on the top right of the screen.
You'll need to enter the hostname of the endpoint you want to communicate with. E.g. this may be stevesie.com - just provide the domain name.
The scheme will typically be https unless you're working with a very old and outdated API!
The default port is 443 for SSL (assuming you're using https), but you can override this - for example if you're using a private API you maintain on a custom port.
We support GET and POST requests. Check the API documentation, but typically most requests will be a GET.
You'll need to declare the path of the request URL, e.g. /cloud/api/v1/apps.
Do not include query parameters here unless they are irregular and should not be escaped, e.g. if you must send a comma (or similar character) raw instead of escaped.
You'll most likely need to send some headers, and typically if the API requires authorization you may send your access token or code through the headers. Each endpoint has a list of headers you can add after creating the endpoint, adding, removing and editing at any time. Each header key must be unique.
Most GET API endpoints will use query parameters for you to specify the inputs to the API. E.g. send the query string for a search term.
You can add these after creating the endpoint, editing or removing at any time.
Each query parameter key must be unique.
Most POST API endpoints will rely on the request body to specify the inputs to the API call.
You'll want to check the documentation or intercept the endpiont, but a common pattern for this is key1=value1&key2=value etc...
When you define the host, path, headers, query parameters and request bodies, you can templatize any parts of the request using standard Jinja notation.
E.g. if you want to look up an ID in the path, you would write the path as something like /api/v1/lookup/.
You will now need to devlare an "input" (defined below) with the variable name user_id so it matches your templatized value and you can then dynamically inject IDs into your API calls.
If you take advantage of templatization, you'll then also need to declare inputs that will prompt the user to provide values or not.
Required: You can declare that an input is required, meaning that the system will always prompt for this value.
Sample Value: For documentation purposes, you can define a sample value. This is helpful to remind yourself if this is a number, string, etc...
Sample Default: You can declare that the sample value provided is also used as the default. This is handy for pagination offsets, e.g. if the API always requires one to be passed but don't want to enter it in each time, you can set the sample and default to 0 and then override if needed.
By default, whenever you create a new app or endpoint, it is private and viewable / usable only to you. This is intended so you can first experiment with and debug your integration privately, protecting any sensitive data in the process.
Once you have an integration working, we highly encourage you to share it with other potential users! You'll see a prompt to publish the app or endpoint and can follow the instructions there to publish, where it will be publicly viewable and also allow other users to access your work. Be 100% sure you've removed all sensitive API keys and information from your work before hitting publish!
Next: API Requests »