Developers/Introduction

fepli API

The fepli API gives your own systems the same view of your programme that admins have in the admin: offers, editions, hosts, accounts, attendances and receipts. It can also do what the admin does, such as publish an offer, confirm an attendance or record a payment.

How it works

The API speaks JSON over HTTPS. Every organisation runs its own fepli, so each 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.

Guides

AuthenticationSend a personal or service account token, and learn what read and write access mean.Service accountsGive an integration or an AI agent its own identity, capped at read-only if you like.PermissionsWhich roles unlock which endpoints, what host users see, and when personal data is masked.End-to-end encryptionRead and write the names of participants where a tenant encrypts them: your own key, the emoji comparison, the wire format.ConventionsIdentifiers, references, dates, amounts, filters and how PATCH works – once, for every endpoint.PaginationWalk through long lists page by page.ErrorsThe status codes the API returns, what each one means, and how to react.Offers on your websiteShow the current offers on your own website or an app, without a token.Support agentsLet an agent answer a verified family’s questions about their own account.UpgradingWhat 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 periods offers belong to, with the tasks that decide when hosts edit offers, families apply and participant lists are released.HostsThe clubs, companies and departments that run offers, with their contact details and members.Host invitationsInvite people to join a host as members, or to register a new host. Resend and withdraw them.AttendancesWho applied for what, and in which state. Apply participants, confirm, waitlist or withdraw them.AccountsFamilies, host users and admins: contact details, roles, participants and balance.ParticipantsThe children and young people who take part, with their attendances by state.EncryptionWhere a tenant encrypts end to end: the team key, your own key, and the emoji comparison that confirms it.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 balance. Add book entries.ConsentsThe consents families and hosts gave, and whether they are still valid.CommentsThe notes admins keep on offers, attendances, people and editions. Read them and add your own.MailingsSend a Rundmail to families or to hosts, as the admin does. Tells families of committed decisions.Sent messagesEvery e-mail and text message the system sent, with its delivery status.Offer categoriesThe categories offers are filed under.Access code listsThe codes an edition can require before families may apply, for programmes open to some families only.SearchOne query across offers, editions, participants, accounts, hosts and receipts.MeWho a token belongs to, what it may do, and which tenant it works for.