Skip to main content
A partner is one of your own customers that calls your Lerian platform from its own systems. Access Manager gives each partner its own applications. You decide what the partner can do and in which part of a product’s data. You also decide its network addresses and its validity window.

​
The building blocks

A partner is a record of your tenant. The rows after it describe what you set for a partner.

​
Products that accept partners

You can give a partner permissions only on a product that accepts partners. A product accepts partners when it publishes a scope catalog with the partner opt-in. To see which products accept partners in your deployment, read the scope catalogs with List scope catalogs. A product accepts partners when its entry has partners: true. A product without an entry has not published a scope catalog. In the Console, the Products step of the new partner page shows the products that do not accept partners as unavailable. Each product has its own page with its restrictions, the fields where the partner names its items, and the refusals it receives:

​
What you need to know

  • Each product sets its own dimensions in its scope catalog. The catalog says if a dimension is required, and if it takes more than one value.
  • Every partner needs a scope in each product that declares dimensions. Give it at least one scope entry for that product. Without one, Access Manager refuses to create or change the partner, with 400 and IDE-1060. A partner saved before this rule, without a scope entry, is refused with 403 on every request to that product until you add one.
  • When a product marks a dimension as required, a partner with permissions on that product needs a scope entry for it. Without it, Access Manager refuses the partner with IDE-0001.
  • A partner reaches only what its permissions and its scope both allow.
  • Access Manager does not check that scope values exist in the product. It stores the values you enter. Copy them from the product’s own API or Console.
  • You cannot delete a partner that has applications. Delete its applications first.
  • Access Manager refuses a permission above the ceiling with IDE-1043. The Console marks it as Not allowed.

​
How a request is decided

Every request that a partner’s application sends to a product is checked against the partner’s record, in this order. The first check that fails decides the answer:
  1. Network address. The caller’s address is checked against the partner’s own IP list, or your tenant’s list when the partner has none.
  2. State. The partner must be active.
  3. Validity window. The request must be inside the partner’s validity window.
  4. Permissions. The product, the resource, and the action must be in the partner’s permissions.
  5. Scope. The items that the request names must be inside the partner’s scope.
The last two checks give the same answer, so a partner cannot use a refusal to learn which items exist outside its scope. The first three checks also apply when the partner requests a token. Each product page lists the codes the partner receives.

​
When a change applies

Every change you make to a partner applies without a new token: its permissions, its scope, its state, its validity window, and its IP list.

​
Next steps

Manage partners in the Console

Create a partner step by step, create its applications, suspend it, or delete it.

Manage partners via API

The partner operations, their fields, examples, and error codes.

Partners in Midaz

Confine a partner to one organization and to its ledgers, accounts, or routes.

Partners in Pix JD

Confine a partner to a direct participant or to one indirect participant.

IP allowlist

Your tenant’s list of trusted network addresses.

Error list