Introduction

fepli API

The fepli API gives your own systems the same view of the holiday programme your team has in the admin: offers, editions, organisers, families, applications and payments. It can also do what the admin does, such as publish an offer, confirm an application or record a payment.

Quickstart API reference

How it works

The API speaks JSON over HTTPS. Every municipality runs its own fepli, so every municipality has its own endpoint: usually /api on the admin's host. See the Quickstart to find yours.

Without a token you can read the published offers of the editions that are online, the same ones the public website shows. The embeds show the same offers on your website.
With a token you see and do what the token's owner may see and do in the admin. A token is either a colleague's personal access token (pat-…) or belongs to a service account (svc-…), a machine identity with its own roles.
Every token is either read-only or read-write. A read-only token can't change anything, whatever its roles are.

Did you use the API back when it only knew offers? Identifiers, filters and a few fields have changed. See Upgrading for what to change in your integration.

Guides

Authentication

Send a personal or service account token, and learn what read and write access mean.

Service accounts

Give an integration or an AI agent its own identity, capped at read-only if you like.

Permissions

Which roles unlock which endpoints, what organisers see, and when personal data is masked.

Conventions

Identifiers, references, dates, amounts, filters and how PATCH works – once, for every endpoint.

Pagination

Walk through long lists page by page.

Errors

The status codes the API returns, what each one means, and how to react.

Offers on your website

Show the current offers on a municipal website or an app, without a token.

Support agents

Let an agent answer a family’s questions – and, if you allow it, act on them.

Upgrading

What changed since the API only knew offers.

Resources

OffersThe activities of an edition, with dates, fees and places. Public without a token; create, change and publish them with one.EditionsThe holiday periods offers belong to, with their phases: editing, applications, holiday, participant lists.OrganisersThe clubs, companies and departments that run offers, with their contact details and team members.InvitationsInvite people into an organiser’s team, or to register a new organiser. Resend and withdraw invitations.ApplicationsWho applied for what, and in which state. Apply participants, confirm, waitlist or withdraw them.AccountsFamilies, organiser team members and admins: contact details, roles, participants and balance.ParticipantsThe children and young people who take part, with their applications by state.ReceiptsPayments, invoices and reversals. Take a payment at the counter, invoice a family, or reverse a receipt.DebtorsEach family’s ledger: what they paid, what is due, and their credit. Add manual bookings.ConsentsThe consents families and organisers gave, and whether they are still valid.CommentsThe notes the team keeps on offers, applications, people and editions. Read them and add your own.OutboxEvery e-mail and text message the system sent, with its delivery status.CategoriesThe categories offers are filed under.Access code listsThe codes an application phase can require, for programmes open to some families only.SearchOne query across offers, editions, organisers, people and receipts.MeWho a token belongs to, what it may do, and which municipality it works for.