API Terms and Conditions
This page explains the access conditions and operating responsibilities for the Requidex Open API and webhooks. Read it alongside the Requidex Terms and Conditions, including section 11 on Open API use, your applicable Order Form and any data-processing or API-access agreement.
Commercial rights, charges, liability, warranties, governing law and any service commitments are set out in those contractual documents. This documentation does not amend them or create additional service commitments. Contact Requidex if you need clarification about how the terms apply to a proposed integration.
Authorised use and access
Use the API only for an approved business purpose and within the companies or agencies, scopes and environment assigned to your credentials. Only documented operations are supported. Write operations require the relevant write scope, the permitted key type and any additional user, record-state or workflow permissions described by the endpoint.
An API response or webhook subscription does not give an integration unrestricted access to a client's records. Filters, field selection, an MSP relationship or a white-labelled interface do not expand the credential's underlying access. Where your integration serves several clients or programmes, maintain their access boundaries throughout your own application, storage and reporting.
Give access to your integration only to people and systems authorised to use the returned data. A backend key that can access several companies is not, by itself, permission for every user of your application to view those companies.
See Authentication and Authorization and Scopes for the technical access model.
Credential security
Keep API keys, webhook signing secrets, upload tokens and temporary file URLs confidential. Store production credentials in protected server-side configuration and restrict who and what can retrieve them.
Do not place a shared API key in a public website, browser bundle, mobile application, source repository, URL, analytics system or support message. Use a dedicated credential for each integration, keep an accountable owner and review access when the integration's purpose or operator changes.
Report suspected credential exposure immediately, revoke the affected key and arrange a replacement. Review relevant usage before restoring the integration. An expiry date or IP allowlist supplements secure credential handling; it does not replace it. The Security page explains the operating controls and incident-response steps.
Data handling and downstream access
API responses may contain personal, workforce, document and financial information. Retrieve only the records and fields needed for the approved purpose, protect copies in transit and at rest, and apply appropriate retention and access controls to exports, caches, backups and logs.
Your integration must account for changes in permissions, records and its authorised purpose. Do not treat previously retrieved data or a cached response as continuing authority to disclose it to another user or organisation. Manage retention, correction and deletion requirements under the applicable agreement and your organisation's data-handling arrangements.
The Privacy Policy and your applicable data-processing agreement describe the relevant privacy framework. Connecting an API key does not approve a new downstream recipient or third-party processing arrangement.
Submitted data and write operations
Validate submitted identifiers, dates, amounts, file contents and business instructions before sending a write request. Apply the approvals and checks appropriate to the operation in your own integration, and retain enough non-sensitive context to investigate an unexpected result.
A successful API write can change live records. It may also create activity records, affect related data or trigger notifications and webhooks as documented by the endpoint. Use approved test data and agree the intended workflow before enabling automated production writes.
Do not assume writes are safe to repeat after a timeout. Confirm the current record state and follow the endpoint's retry rules. Potential worker matches, rejected transitions and permission failures require the documented resolution process rather than repeated attempts to bypass the check.
An invoice-status update records a status in Requidex; it does not itself transfer funds. Document-check results and stored verification information must be used within the relevant business review process. See the endpoint reference for the meaning and limitations of each operation.
Fair use and service protection
Respect the configured request quotas, documented limits and technical access controls. Coordinate applications sharing a key so their combined workload remains within its limits.
Do not evade limits by cycling credentials, distribute requests to bypass access restrictions, attempt to retrieve records outside your permitted scope, or interfere with the platform's operation. Agree the scope and timing of any production load or security testing with Requidex before starting it.
Use bounded retries, efficient filters and appropriate refresh schedules. Repeated failures must be investigated rather than retried indefinitely. The Rate Limits and Developer Guidelines pages describe the expected request and recovery patterns.
Webhook receiver responsibilities
Protect each receiving endpoint and verify delivery signatures using the subscription's signing secret and the original request-body bytes. Reject invalid deliveries, deduplicate accepted events and handle out-of-order arrival.
Acknowledge an event after accepting it for processing. Delivery attempts are bounded, so your integration must monitor failures and reconcile important records through the API where needed. Do not rely on webhook arrival order, indefinite retry or the payload as a complete record snapshot.
Webhook subscriptions and API credentials are separate. Reading the referenced record still requires the relevant API scope and company or agency access. See Webhooks for the delivery contract and event-specific restrictions.
Third-party services and custom applications
You are responsible for the configuration and operation of your own middleware, hosting, reporting tools and other connected services. Review which data those services receive and who can access it, including through dashboards, exported files and AI tools.
Where an integration sends data to a third party, establish the appropriate authorisation, contractual arrangements and safeguards before enabling that transfer. Do not infer a third party's storage location, retention rules, security controls or use of data from the fact that it can connect to Requidex. See Data, Security & Privacy for customer-connected AI considerations.
Changes, restriction and revocation
Review technical changes through Versioning, the Changelog and the current OpenAPI specification. Examples and documentation describe the supported interface; they are not a commitment to deliver an unlisted endpoint or feature.
Credentials can expire, be revoked or become unusable when access assignments change. Inactive keys are also subject to the lifecycle rules described in Authentication. Your integration must stop or restrict affected processing when access is withdrawn.
Requidex's contractual rights concerning monitoring, restriction, suspension and service changes are set out in the published terms and applicable agreement. Contact Requidex before relying on particular availability, support, capacity or notice arrangements for a business-critical workflow.
Support and contractual questions
For integration support, provide the HTTP method and path, UTC time, response status and error code, request ID, and the key name or prefix where available. Exclude API keys, signing secrets, personal documents and unredacted sensitive responses.
Contact support@requidex.com for technical or access questions. Pricing, standard contract terms and any additional API or service requirements should be confirmed through your Requidex commercial contact and the applicable written agreement.