Administration

The Admin section is for admins and, for some pages, managers.

Staff

Admins. Admin → Staff lists every staff account, with its role and language.

• Add staff: their name, email, a starting password, their role and their language. Each role's line says what it opens (see Roles).
• Manage on a person changes their name, role or language, or sets a New password, for someone who has forgotten theirs. Everyone changes their own on Your account.
• Remove signs them out at once and keeps them off; Restore brings them back. Removed staff stay named on everything they did.

With single sign-on, a person's role is set by the identity provider at every sign-in, and the role here follows it.

Integrations

Admins. Admin → Integrations connects other systems to BikeKit.

Open data gives the addresses of the public GBFS feed and the MDS feed (see Open data).

API clients are other systems that call BikeKit as themselves: the city's own app opening riders' accounts, its accounting tool reading invoices, its mobility platform reading MDS.

1. Add client, with a name and what it may do: Open riders' accounts, Read invoices, Read MDS.
2. Copy the Client ID and Client secret it shows. The secret is shown once.
3. The system exchanges them for a one-hour token (POST /auth/token with grant_type: client_credentials) and calls the API with it.

Turn off stops a client at once, tokens included. The activity log names each client like a person.

Webhooks tell another system the moment something happens, rather than it asking: a ride ending, a sale, an invoice issued, a work order changing, an alert, a closure, a message, a station changing, a privacy request.

1. Add webhook, with the receiver's URL and, optionally, which events it wants. The receiver must be on the public internet: an address on your own network, such as 10.0.0.5, is refused, and a delivery to a name that points to one fails without being sent (see Security).
2. Copy its signing secret, shown once. Each delivery is a batch of events, signed in the X-BikeKit-Signature header (sha256= and the HMAC-SHA256 of the body with that secret), so the receiver can check it came from you.
3. Deliveries arrive in order and at least once. A receiver that fails is tried again, waiting longer each time, up to every ten minutes, until it answers.

The list shows each webhook's last delivery and whether it is failing; a failing webhook also shows on the managers' home page. Turn off stops it.

Export

Managers and admins. Admin → Export downloads the records as CSV files, one per kind: riders, rides, payments, passes, invoices, work orders, stations, bikes and so on. Choose a range of days for the rows created in it, or download every row from the beginning. Use it for your own analysis, for an auditor, or to move your data elsewhere.

Activity log

Managers and admins. Admin → Activity log records every change a person or API client made: who, when, what, to which record, and the reason they gave. Search it by topic, person or record. It can't be edited.

The system page

Managers and admins. Admin → System shows how the server is doing, live, with no monitoring tools needed:

• Health: whether the database answers and how fast, how long the server has been up, its version, and the clock speed (1× except in a simulated city);
• Capacity: database connections in use and the queue of bike positions waiting to be written;
• Stations: how many are reporting and silent, and how long since they were last heard;
• Webhooks: active, failing, and the oldest event not yet delivered;
• Open reconciliations, by kind: where stations and the records disagreed and nobody has settled it yet;
• the busiest API routes and the background jobs over the last minute, with their speed and any failures, calls to stations and the payment provider, and the backoffice server's own figures.

The same figures are available to Prometheus on the metrics port (see Monitoring).