e-copedia hjælpecenter
Fetching tokens via RedirectURL
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:
Access your developer agreement in e-conomic.
Find the app you want to configure under Apps.
Click Tokens for the app.
Enter your URL in the
redirectURLfield 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 |
| Must be the registered domain or a subdomain of it |
Scheme |
| HTTPS cannot be downgraded to HTTP |
Port |
| Can differ |
Path |
| Can differ |
Query parameters |
| Can differ |
Fragment |
| 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.comyou can redirect to the following examples:
https://example.com/callback
https://example.com/customer/111/installed
https://example.com/callback?state=qwe123All 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.comHowever, 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.comregistering 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
Domain must be the registered domain, or a subdomain of it. Downward only.
Scheme
https. Alsohttp, but only if the app registered anhttpURL itself.Path, query, port, fragment free to include
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.