Search offers
This guide gets you from zero to your first OMSA .
You will:
- Model who is travelling.
- Send your first
search-offersprocess request. - Understand the basics of an OMSA
OfferCollectionresponse.
Eager to start experimenting with code? Explore the API spec directly at https://developer.entur.no/apis/omsa/latest/openapi.json (does not require auth).
Before you begin
To use this guide, you need to:
- Be an authorised Entur partner.
- Have OAuth2 client credentials (
client_idandclient_secret). - Have header values for and .
- Use the OMSA dev base URL
https://api.dev.entur.io/omsa/v1.
Read more about authentication here.
1. Specify who is travelling
When searching for offers, OMSA supports two traveller models:
individual_traveller: an identifiable traveller (with specific attributes such as age, name, and possibly other personal details).user_profile: an anonymous traveller profile with a count.
You can use one of them, or both in the same request.
Both models require an id that you supply. It can be any string up to 200 characters, so you can reuse IDs from your own system.
OMSA keeps these IDs throughout the purchase. You refer to them as travellerId when you update or remove a traveller in a draft package.
Code
2. Search for your first offer
Use the search-offers process to send your first request.
Using place references
OMSA supports several place models in specification, most commonly:
- Fare zones (
ORG:FareZone:*) - Stop places (
NSR:StopPlace:*) - GPS coordinates (
GPS:lat,long[,alt])
Searching with zones or stop places is a common way to search for simple single-product offers, typically to let the user purchase a single ticket in a specific zone or set of zones.
These place references are used throughout the Entur platform and are based on concepts. Read about the and concepts, or see all accepted formats for OMSA .
Code
Please use FareZone in your application. Entur still supports the alternative spelling TariffZone in some services, but note that this spelling is deprecated. OMSA does NOT support TariffZone.
Using trip patterns from Journey Planner
You can also use a TripPattern from the Entur Journey Planner to search for offers, which is often the preferred way to search for offers.
Code
When using a TripPattern, the client is responsible for the integration with Entur's Journey Planner and any use of Entur's Geocoder API for autocompletion or reverse geocoding.
3. Understand the response
Confirm that:
- The request returns HTTP
200. - The response contains at least one .
- Returned offers match expected s and traveller inputs.
Example response
Code
OMSA returns offers with Leg objects, even for simple Zone-Zone or StopPlace-StopPlace searches. In these cases, the leg represents a single traveller on a single product. To see which traveller belongs to which product, check the legs.
If requests fail with 401 or 403, verify token scopes and header values before retrying.
Troubleshooting tips
- If you receive an empty
offersarray, check that yourspecificationparameters (place IDs, time range) align with available data in the dev environment. - Use the OMSA API spec and error messages to debug issues. Common errors include invalid place IDs, duplicate traveller IDs, or missing required fields and headers.
- For authentication issues, ensure your OAuth2 token is valid and has the necessary scopes for OMSA access and the distribution channel and POS you are using.
- If you encounter unexpected errors or need further assistance, contact Entur support with details of your request and response for help. Include the
X-Correlation-IDfrom your response headers to help us trace the problematic requests.
Next steps
- Make your first purchase from one of the offers in the response.
- Apply discounts for eligible travellers with
entitlements, e.g. students, employees etc. (link coming soon). - More
search-offersrequests, e.g. with aTripPatternfrom the Entur Journey Planner or a group of travellers (link coming soon).