Operator integrations vs partner integrations
There are two ways to connect to the Stora API:| Operator integration | Partner integration | |
|---|---|---|
| Who builds it | The operator (or their developer) | A third-party company |
| Auth flow | Access Token or Client Credentials | Authorization Code (required) |
| Scope | Single operator’s data | Multiple operators, each authorising independently |
| Setup | Self-serve in BackOffice | Managed by Stora |
| Example | Internal reporting dashboard, custom booking widget | Smart entry provider, CRM connector, accounting sync |
How the partner programme works
Get in touch
Contact us with details of what your integration does, which Stora resources it needs, and the problem it solves for operators.
Development
We’ll set up OAuth 2.0 testing credentials with a set of selected test operators. You build your integration using the Authorization Code flow and our test environment.
Review
Submit your integration for review. We’ll check your use of scopes, External Events implementation, error handling, and how you present the connection flow to operators.
Technical requirements
These apply to all partner integrations. Meeting them is part of the review process.Authentication
- You must use the OAuth 2.0 Authorization Code flow. No other flow is accepted for partner integrations.
- Handle token refresh correctly — access tokens expire after 2 hours.
- Never ask operators to share or copy-paste credentials. Your integration should handle the OAuth flow end-to-end.
- Consider using PKCE if your integration runs in a distributed or client-side environment.
External Events
When your integration takes an action in Stora on behalf of an operator, it must be visible to them. You’re required to create Timeline Events for actions originating on your platform. For example:- “Unit locked via YourApp”
- “Customer contacted via YourApp”
Rate limits
Standard rate limits apply (10 requests/second, 60 requests/minute). Strategic partners may negotiate higher limits. Your integration must implement backoff when receiving429 responses — see rate limiting.
Idempotency
UseIdempotency-Key headers on all POST requests to prevent duplicate operations. See idempotent requests.
Error handling
Handle all documented error codes gracefully. Do not retry indefinitely on4xx errors.
Metadata
Use themetadata field to store your own references on supported resources (contacts, orders, tasks, notes, webhook endpoints) rather than maintaining external mapping tables.
Webhooks
Use webhooks to react to Stora events rather than polling. This is more efficient, gives you real-time data, and respects rate limits.Scope principles
We follow the principle of least privilege. Your production credentials will be scoped to only the permissions your integration needs — nothing more. During development, your test credentials will have all scopes so you can explore freely. At review time, we’ll agree on the minimum set of scopes for production. If you need additional scopes after launch (e.g. you’re adding a new feature), submit a request with justification. Operators who have already connected will need to re-authorise to grant the new scopes.Get started
Ready to build a partner integration? Contact us with:- What your integration does
- Which Stora resources it needs access to
- The problem it solves for self-storage operators