e-copedia hjælpecenter

Why GET /self should be your first API request

Use get /self and get to know your tokens

API-copedia
Sidst opdateret:
Skrevet af Charles J

See documentation here
​
The GET /self endpoint is one of the most important endpoints in the e-conomic RESTAPI.
​

Every integration should call GET /self immediately after obtaining an agreementGrantToken.

While many endpoints return accounting data, GET /self tells you who you're connected to, what you're connected to, and what your integration is capable of doing.

Think of it as the endpoint that validates your connection before interacting with any other API resource.

Obs

💡GET /self is currently only available via our RESTAPI

1. Verify the Connection

The first purpose of GET /self is verifying that the supplied credentials are valid.

If the request succeeds, you know that:

  • the appSecretToken is valid.

  • the agreementGrantToken is valid.

  • the application currently has access to the agreement.

If the request returns:

401 Unauthorized

a typical response is:

{"message": "Token does not correspond to a valid grant.", "errorCode": "E02250" }

Common reasons include:

  • The appSecretToken is invalid.

  • The agreementGrantToken is invalid.

  • The application has been removed from the agreement.

  • The stored agreementGrantToken is no longer valid.

When this occurs, the integration should stop using the stored agreementGrantToken. The customer should reinstall or reconnect the application to obtain a new agreementGrantToken or parse a proper agreementGrantToken found via the GUI.​
​

Obs

​ ⭐ E-conomic users can find their tokens by following this guide.

💡 Furthermore it's possible to see all active tokens via our partnerAPI

2. Verify the Connected Agreement

The agreementGrantToken itself does not identify which agreement granted access.

GET /self returns information such as:

  • agreementNumber

  • company.companyIdentificationNumber

  • company.name

This allows your integration to verify that the customer connected the intended agreement.

3. Determine the Agreement's Capabilities

The response contains information about the connected agreement:

{
"agreementType":{
"agreementTypeNumber": 1,
"name": "denmark",
"subscriptionPlanLevel": "{subscriptionPlan}"}
}

The subscriptionPlanLevel indicates which subscription plan the connected agreement is using.

This allows an integration to determine whether the agreement supports write operations through the public API.

As a general rule:

Agreement

API Capabilities

Internal agreement types

Read-only

Basis

Read-only

Plus and above

Full Create, Read, Update and Delete (CRUD) support

Both internal agreements and agreements using the Basis subscription only support read operations through the public API.

By checking subscriptionPlanLevel during onboarding, an integration can determine whether write operations are expected to be available before attempting them.

If a write operation is attempted against a read-only agreement, the API returns:

{
"title": "The license is read-only.",
"status": 403,
"detail": "Some e-conomic subscriptions are not allowed to change data via public APIs. Only read operations are allowed."
}

4. Verify the Connected Application

The response also contains information about the connected application.

Example:

{
"application": {
"appNumber": {appNumber,
"name": "{integrationName}"
}
}

The appNumber uniquely identifies the installed application.

This is particularly useful when:

  • Supporting multiple applications.

  • Separating production and sandbox environments.

  • Verifying that the customer installed the intended application.

  • Troubleshooting environments where several applications may exist.

Obs

💡Sharing your app number with the API support will help us immensely when troubleshooting errors related to a specific app

To summarize

Before making any other API request, it allows your integration to answer the following questions:

  • Is the appSecretToken valid?

  • Is the agreementGrantToken valid?

  • Which agreementNumber is connected?

  • Which company is connected - Check company.companyIdentificationNumber?

  • Which subscriptionPlanLevel does the agreement have?

  • Does the agreement support write operations via the subscriptionPlan?

  • Which appNumber is connected?

  • Which roles has the application requested?

For these reasons, we recommend calling GET /self immediately after obtaining an agreementGrantToken and before interacting with any other API resources.

Var denne artikel nyttig?