e-copedia hjælpecenter

Fetching tokens via RedirectURL

Sidst opdateret:
Skrevet af Charles J

RedirectURLs when installing an app

When installing an app in e-conomic, you can use a redirectUrl to redirect the user back to your integration once the installation has been completed.

The redirect contains the generated AgreementGrantToken, which can then be used together with your app credentials when making requests to the e-conomic API.

This guide will walk you through how the redirectURL field functions, and why certain redirects might lead to the installation of the app failing.

Registering your redirectURL

Before using a redirectUrl in your installation flow, you need to register a redirect URL for your app.

You can configure it directly from your developer agreement:

  1. Access your developer agreement in e-conomic.

  2. Find the app you want to configure under Apps.

  3. Click Tokens for the app.

  4. Enter your URL in the redirectURL field and save.

This becomes the registered redirectURL for your app and defines which domains can be used when redirecting users after an installation.

For example, you could register:

https://example.com

When an installation is completed using a redirectUrl, we compare its domain and scheme with the redirectURL registered here.

Obs

⭐ Tip: If your integration uses multiple subdomains, such as separate production, test and development environments, we recommend registering the common parent domain. For example, registering https://example.com allows you to redirect to app.example.com, test.example.com and dev.example.com.

The remaining parts of the URL can be changed dynamically:

URL component

Example

Validation

Domain / host

example.com

Must be the registered domain or a subdomain of it

Scheme

https://

HTTPS cannot be downgraded to HTTP

Port

:8080

Can differ

Path

/callback

Can differ

Query parameters

?customer=ID

Can differ

Fragment

#success

Can differ

This means that you don't need to register the complete callback URL that will be used for every installation.

For example, if you have registered:

https://example.com

you can redirect to the following examples:

https://example.com/callback
https://example.com/customer/111/installed
https://example.com/callback?state=qwe123

All of these use the same registered domain, while the path and query parameters are free to change.

Using subdomains

A registered domain also allows redirects to its subdomains.

If you register:

https://example.com

The following would be usable

https://example.com
https://app.example.com
https://test.example.com
https://dev.example.com

However, this only works downwards from the domain you registered.

For example, if you instead register:

https://app.example.com

the following would apply:

Would function:

https://app.example.com
https://api.app.example.com


Wouldn't function:

https://example.com
https://test.example.com
https://dev.example.com

test.example.com is a sibling of app.example.com, rather than a subdomain beneath it, and is therefore not covered by the registeredURL.

We recommend registering your parent domain

If your integration uses several environments, we recommend registering the common parent domain.

For example, if you use:

https://app.example.com
https://test.example.com
https://dev.example.com

registering https://example.com allows all three to be used with the same app.

Registering only https://app.example.com would limit redirects to that particular branch of the domain. This is useful in case several subdomains are in use without having to create several apps.

Obs

💡The TL;DR

  1. Domain must be the registered domain, or a subdomain of it. Downward only.

  2. Schemehttps . Also http , but only if the app registered an http URL itself.

  3. Path, query, port, fragment free to include

  4. No registered URL, or we can't verify it = no redirect.

The domain must match completely.

The validation is based on the actual domain structure and not simply the name appearing within the URL.

With https://example.com registered, a different top-level domain, such as .dk instead of .com, is a different domain and will therefore not be accepted.

Var denne artikel nyttig?