Rehive has several recommendations for building extensions that we encourage developers to follow, especially if they are seeking approval for the addition of a publicly available extension.
Authenticate all incoming requests
Ensure that all incoming requests (even those that appear to be from Rehive) are authenticated. There are tow primary ways you can do this:
- For user authenticated request: expect a Rehive auth token to be included in an
Authorizationheader and then call the platform to see if it is a real user.
- For webhook requests: check the
Authorizationheader. This can also be used to identify webhooks for specific companies.
Build with multi-company in mind
Extensions should built to support a multi company use case, rather than only support a single company on Rehive. This will allow your extension to be used on test companies (should it be a private extension) or at a later stage be used as a public company.
To ensure an extension is not locked to a single company ensure that:
- On activation store a company relationship to the extension user (and token)
- On activation set a
secreton the company in the extension that can be used for webhooks.
- Make all requests on the extension API only operate on the company of the user accessing the API (see above for authentication).
- Make all webhook handlers operate on the correct company data only (and verify against the
- Never hardcore any company specific logic.
Use the minimum permissions required
Do not set service users to have all admin permissions unless for some reason you are actually going to use all those permissions in your service. It is best to reduce your required permissions to the minimum required to operate the extension and no more or less.
Use asynchronous processing for slow requests
If a request is likely to take a long time to process then prefer asynchronous processing over holding the request open indefinitely. For instance, if you need to generate an export on a very large data set, then do this as a background task instead of in the HTTP request/response cycle.
This is particularly true of the following:
- activate : The platform will timeout after 10 seconds.
- deactivate : The platform will timeout after 10 seconds.
- webhooks : The platform will timeout after 5 seconds.
When processing webhooks it is almost always better practice to receive the webhook from the platform, log it to a queue (or database) and then issue a task to handle that webhook in a separate process. This way connection errors and timeouts cannot cause as many issues and you will also have a log of the webhooks which will help with troubleshooting.
Use platform idempotency
If you are concerned about mistakenly replaying an action on the platform due to a bug or a race condition, then use platform level idempotency on POST, PATCH and PUT requests.
Account for pagination
If tring to get all the results from a platform listing ensure that you take into account that most listing pages are paginated. This means that you will need to iterate through each page of results if you are trying to fetch everything.
Account for throttling
Platform endpoints are throttled if too many requests are executed at the same time. You should build in a manner that is resilient to throttling. The platform documentation has a section on throttling.
Monitor the changelog and deprecation timeline.
The changelog and to a lesser extent the deprecation timeline are updated regularly. It is a good idea to stay ahead of the curve and immediately make use of new feature or prepare for features that are getting removed soon.