Mobile API: moving from v3 to v5

What this page is

Version 5 of the Mobile API does everything version 3 does: the member's objects, bookings, flight log, balance and transactions, and the bookings the member makes. What has changed is how the app and the member are identified, the addresses, the form of the replies, the status codes and the names and types of the values. This page lists every difference an app notices, with what to change. The names of version 3's functions are used as headings so the page can be read function by function.

Version 3 keeps working until 2027-09-30, but it will not be developed or changed: new functions are only added to version 5. Every v3 reply has a Deprecation header, a Sunset header with the end date and a Link header pointing to this page. From 2027-10-01 every v3 call is answered with 410 Gone.

Version 5 is built on the same framework as the Main API v5, so an app that also uses the Main API meets the same rules there. It is described in full on the documentation page. The same description can be fetched as openapi.yaml (OpenAPI 3.0) and as a Postman collection.

The most common changes

Every app needs the changes in this list. The sections after it have the details, function by function.

1. Get a client id from myWebLog for your app and register its redirect addresses (write to support@myweblog.se). An app with a server of its own also gets a key, through a link that works once; keep it out of source code repositories and out of app binaries that users can unpack. A native app without a server gets no key (a public client). They replace app_token.
2. Log the member in once with OAuth 2.1, the authorization code flow with PKCE: the app opens myWebLog's login page in the browser, the member logs in there, and the app exchanges the code at POST /oauth/token. The app never sees the password, and your own login screen goes. Keep the access token and the refresh token; send Authorization: Bearer <access token> with every other call, and renew with the refresh token when a call answers 401. See Authentication.
3. Call one address per function with the HTTP method that fits, instead of api_mobile.php with qtype: GET /bookings, POST /bookings, POST /bookings/{id}/cancel and so on. See Where each function went.
4. Read the result from data. One item is an object; a list is an array under data with meta and links beside it. Result, qType and APIVersion are gone.
5. Fetch the organization once with GET /organization. v3 sent orgData with every reply; v5 does not repeat it.
6. Read errors from the HTTP status code and a Problem Details body with code and title, instead of Error[{Code, Message}] with status 200. A refused booking rule is 409.
7. Read times as ISO 8601 text with a zone, 2026-10-04T08:00:00Z or 2026-10-04T10:00:00+02:00, and send them the same way. v3 gave Unix timestamps for bookings and bare clock times for flights.
8. Read yes and no as true and false (v3: 1 and 0), amounts and totals as numbers (v3: text such as "1.0000"), and member numbers as text.
9. Read a list page by page: follow links.next until it is null. v3's limit cut the list; v5's limit and offset page through it.
10. Send JSON in the body of a POST, with Content-Type: application/json, except to the two /oauth endpoints, which take form data. returnType, charset and language are gone: replies are JSON in UTF-8, and the language of the booking messages comes from the Accept-Language header.
11. Remove parameters the endpoint does not have. v3 ignored them; v5 answers 400 and names them.

The rules that changed everywhere

Address and call

Authentication: OAuth 2.1

v3 identified the app with app_token and the member with mwl_u and mwl_p on every call, where mwl_p was the password or the user token from Login. v5 separates the two and uses OAuth 2.1 (the authorization code flow with PKCE), which every platform has a client library for. There is no password grant: no app ever handles a member's password.

Replies

Errors

Lists

Headers and limits

Function by function

Where each function went

Login, GetUserdata and GetBalance

The login gives tokens, not the member: fetch the member with GET /me after it. GetUserdata and GetBalance both became GET /me.

orgData

v3 sent the organization with every reply as orgData. v5 gives it once, with GET /organization, with the fields an app needs and nothing else.

GetOrgSettings

GET /organization/settings. The same settings, those the organization has marked "show in the app" on the website, as a list under data instead of orgSettings. Each has id (the setting type, as before), value, value_type and the website's own fields for it.

GetObjects

GET /objects gives the same objects in the same order. v3 gave everything it had about every object, including the status, the remarks and the picture; v5 gives the basic fields and adds the rest only when asked, with include=. That is what makes the list fast.

GetBookings

GET /bookings gives what the booking calendar on the website shows the member, with the bookings in the queue last. The filters have new names; the sun times are a resource of their own.

CreateBooking

POST /bookings with a JSON body. The same rules and the same messages as before, since the booking is made by the website's booking class as in v3.

CutBooking and DeleteBooking

GetTransactions

GET /transactions, newest first as before, 20 per page unless limit says otherwise, and a year back unless date_from says otherwise.

GetFlightLog and GetFlightLogReversed

GET /flightlogs, oldest first; order=desc is what GetFlightLogReversed was. The fields are those of the Main API v5's flight log, so the clock times are points in time with a zone, not bare clock times, and the totals are numbers.

Error codes

v3 answered every error with status 200 and a list of Error items. v5 answers with the status code and one code. The full v5 table is on the documentation page.

Help

Questions about moving to version 5 are answered by support@myweblog.se. Every reply from v5 has a Request-Id header; quote it when the question is about a certain call.