Skip to main content

Back-office API

Our Back-office API is a RESTful API that enables you to automate operations for your end-customers.

You can test our Back-office API in the Sandbox environment, which does not affect your live data or interact with any banking networks. The environment that you use (Sandbox or Live) determines whether our platform treats the request as a test request or a live request. The API endpoints and API keys for the two environments are different.

When you get started with Weavr, you receive an account in the Sandbox environment where you can choose the appropriate financial product template for your app. You get access to the Live environment after we review your business (KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers.) and your app.

After you get sandbox access and configure your app profilesProfile A template defining the configuration for one type of object - corporate identity, consumer identity, managed account, managed card, transfer, or outgoing wire transfer. When you create one of these objects you reference its Profile ID, which tells Weavr which limits, currencies, supported countries, branding, and fees to apply. Your programme ships with one or more Profile IDs per supported object type., you can start building your app. API environment URLs are as follows.

EnvironmentEndpoint
Sandboxhttps://sandbox.weavr.io/multi/backoffice
Liveon request

Back-office operations​

The Weavr Back-office API facilitates the following day-to-day back office operations:

  • Charge fee to a corporate or a consumer
  • Get a managed accountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr.'s details
  • Get a managed accountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. statement
  • Get a managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User.'s details
  • Get a managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User. statement
  • Create/update/delete/get spend rules for a managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User.
  • Create/get a transfer transaction
  • Get all transfer transaction
  • Un/block a card
  • Remove a card

Calling the Back-office APIs​

Before running any API call from the Back-office API set, you need to obtain a token representing the given identity. This token can be obtained through the access_token method.

POST/backoffice/access_tokenTry it

See the full Back-office API reference for complete endpoint documentation.

API conventions​

Handling errors​

When you invoke our Back-office API, you may encounter errors, which may be caused by the request or by the server. Our API returns errors according to the standard HTTP status code scheme. For example, you may receive the following codes:

  • 4XX: Client error
    • 400: Bad request
    • 401: Unauthorized
    • 403: Not authenticated
    • 409: Conflict, together with an error code that identifies the issue
  • 5XX: Server error
    • 500: Internal server error
    • 503: Service unavailable

Idempotent requests​

GET and DELETE operations are inherently idempotent. Selected POST and PATCH operations also support idempotencyIdempotency A property of an API that guarantees calling it multiple times with the same inputs produces the same result, with no additional side effects beyond the first call. An idempotent endpoint can therefore be safely retried after network errors or timeouts without risking duplicate transactions or state changes. through the optional idempotency-ref request header - check each endpoint in the Back-office API reference to confirm.

The semantics, retry guidance, and reference uniqueness window match the main API. See Idempotent requests for the full guidelines.