Pennylane API Integration
Pennylane is a French accounting platform for small and mid-sized companies and for the accounting firms that work with them. It covers invoicing, supplier invoices, VAT and the ledger, and it is growing quickly in its home market. Connect it through Maesn and you reach it with the same REST API and the same data model as every other supported system.
What a Pennylane integration costs
Pennylane is the system in this catalogue where the build is not the long pole. Getting a credential is, and it happens before any code runs. Here is what the integration actually asks of you, and what Maesn takes off the table.
The partner step, walked with you
Pennylane hands out no credentials on a form. Its partnerships team reviews your integration first, and the client ID and secret follow once that review is done. The secret is shown a single time and cannot be retrieved later, so losing it means a new application rather than a reset. Maesn does that step with you rather than pointing at a form, and provides a sandbox in the meantime: Pennylane publishes no free trial account, so without one there is nothing to build against.
The ceiling stated, not glossed over
Pennylane allows 25 requests every 5 seconds, counted per token and across all endpoints, in the sandbox as well as in production. Creating a single customer invoice costs several sequential calls against that same budget. Maesn runs the orchestration and returns one error contract for the 429, so the retry logic is written once rather than once per system.
A delta pull on the filter you already wrote
Pennylane's webhooks are in beta and its own documentation recommends the changelog endpoints instead, and no event is enabled here today. What replaces it is a scheduled read on the same filter and the same pagination you use for every other system, with the cursor normalised away.
What reaches your code is a REST call and an account key. The slow part of Pennylane is the credential rather than the build, and it is a step you take once for every customer who follows.
A short call is usually enough to tell whether Maesn fits your use case.
Clockin turned integrations into a way into new markets
Clockin digitises time tracking for small and mid-sized businesses. The integrations they built stopped being a support cost and started bringing customers in, which is the same trade a place in the Pennylane ecosystem offers a product that wants to reach French companies and their accountants.
“We use Maesn to successfully leverage integrations and partnerships as a key driver for lead generation and expansion into new markets and customer segments.”
Three reasons to reach the Pennylane API through Maesn
Connecting Pennylane directly is a manageable project once the credential exists. Keeping it alive through token rotation, staying inside one shared request budget and then adding the next system is the part that decides your roadmap.
The Pennylane-specific work stays here
Access tokens last 24 hours, and every refresh invalidates the refresh token it used. Two of your workers refreshing in the same second therefore cancel each other out and send that customer back to the consent screen. Maesn refreshes each connected customer in one place and in order, so the race cannot happen, and re-sends the filter that Pennylane's cursor drops between pages. None of it reaches your code.
What is switched on, in writing
Customers and suppliers come back readable and writable, which is the counterparty pair every payables and receivables flow starts from. Read and write cover the same list here, so a record that arrives from Pennylane can be written back to Pennylane without a second mapping. Everything beyond that list is available on request.
The next system costs nothing
Once Pennylane runs, every other supported accounting and ERP system answers on the same interface with the same data model. The two headers stay the same and the change-detection loop you wrote here keeps working. Your second integration is a configuration step rather than a second project.
Pennylane access runs through its partner programme
Most providers stop at the API. Maesn does the technical enablement and the relationship, and on Pennylane the two are the same conversation: the credential your integration needs is the outcome of the partnership rather than something you configure before it.
Technical enablement
One integration against the Unified API and one data model, identical to every other system Maesn supports. Your engineers meet the same interface here as they will for the next system.
Partnership support
Maesn takes you through the Pennylane partnership step, from the technical requirements to the submission, rather than handing you a form and a link.
The relationship comes before the credential
Pennylane's own documentation sends developers to its partnerships team to register an application, and the client ID and secret arrive once that application has been validated. There is no self-service route to a production credential, and neither side publishes how long validation takes, so it belongs in the plan as a lead time.
Production listings run on OAuth
A company API token is enough to try things out in a sandbox, and Pennylane's own guides use one for exactly that. For an integration published through its marketplace it requires OAuth 2.0 instead, so the flow you ship is the one described in the authentication section above rather than the one you prototyped with. Worth knowing before the prototype, not after.
The audience is French companies and their accountants
Pennylane sits between businesses and the accounting firms that keep their books, and its partner programme is run out of France in French. That is who a listing puts your product in front of, and it is worth knowing which of the two you are selling to.
The integration runs under your product's name, and the partner status is yours rather than ours. Maesn is the layer behind it.
We go through the Pennylane requirements and the submission with you.
One Pennylane client of your own, refreshed for you
Pennylane authenticates with OAuth 2.0, and the application your customers authorise is yours rather than Maesn's. It is the plain redirect flow: your customer visits Pennylane's consent screen once, and the account key comes back to you afterwards. No separate company selection step is needed, because a Pennylane token already names the company it is scoped to.
- OAuth 2.0
- Client credentials issued by Pennylane
One integration, every customer. Maesn holds the credentials and runs the handshake, the rotation and the re-authentication behind them.
- Your client credentials
- The client ID and secret Pennylane issued to you are submitted once and used for every connection afterwards, so the code exchange runs here rather than in your backend. What your code holds is an account key per customer.
- The token cycle, which is the part that bites
- Access tokens last 24 hours. Every refresh immediately invalidates the refresh token it consumed and returns a new one, and the refresh window closes after 90 days. Maesn keeps the current pair for each connected customer and refreshes them one at a time, so a race between two of your workers cannot strand anybody.
Pennylane scopes a token either to one company or, for accounting firms, to all the companies that firm manages, and in the second case each call still has to name the company it is for. That is a property of the token rather than of the flow, so it is worth confirming which of the two your customers hold before you design the connect step.
- 1
Your customer starts in your product
You send them into the flow and Maesn opens Pennylane's consent screen. It carries your application's name, because the client is registered to your company, so the connection reads as yours rather than as a third party's.
- 2
Pennylane returns to Maesn
The callback on your client points at Maesn, so Maesn receives the authorisation code and exchanges it for the first access and refresh token. That exchange never runs in your backend, and your customer lands back in your product with nothing to paste.
- 3
You work with one account key
Maesn stores the connection and returns an account key. From there every request carries your API key plus that account key, the same two headers you already send for every other system in the catalogue.
Every system in the catalogue authenticates differently, and Pennylane is the case where the credential is hard to obtain and then easy to lose: a refresh token that is used twice is gone, and the end user who connected the account has to go through consent again. Unified authentication is where that lives. The rotation, the storage of the current pair and the serialised refresh are handled once for every system rather than once per system, so nothing about the token cycle reaches the code you write.
Change on Pennylane arrives on your schedule
Change detection on Pennylane is a scheduled read, and it is the same scheduled read you already run for every other system in the catalogue. Pennylane's own webhooks are in beta, and its documentation recommends the changelog endpoints instead while that lasts, so pulling here is the vendor's own recommendation rather than a workaround.
Three events, all of them in beta, and Pennylane's own advice is to fall back on its changelog endpoints while that lasts. A changelog entry reports a resource ID and an operation rather than the record itself, so something still has to read the object afterwards.
One scheduled read, with the same filter and the same pagination you use for every other system. The code that detects change on Pennylane is the code you already wrote, pointed at a different account key.
The interval is a product decision with a hard edge behind it: Pennylane keeps four weeks of change history and will not answer for anything older. Inside that window a delta pull catches up cleanly after downtime, which a missed push never does. Outside it, what is left is a full comparison.
Writing change detection once per system is where the cost of a direct integration shows up most plainly: a loop for Pennylane, then another one for the next system with its own filter syntax and its own idea of what a page is. Pennylane pages with a cursor that carries your position and not your filter, so a request that forgets to re-send it comes back with unfiltered rows rather than an error. One way to filter and page is what removes that class of mistake. What you handle through the event model and what you pull on a schedule stay two paths, and only one of them is Pennylane’s today.
What Pennylane asks for up front
Most of this list is about the credential rather than the code, because on Pennylane the credential comes first. Four things are worth having decided before you start.
- A Pennylane OAuth client, issued by their partnerships team
- Not a self-service registration. Pennylane validates the integration first and then hands over a client ID and secret, and the secret cannot be retrieved afterwards. Losing it means a new application rather than a reset.
- The eleven scopes that client has to carry
- Customers, suppliers, customer and supplier invoices, the ledger, file attachments, categories, products and quotes, plus bank accounts and transactions as read only. The list is in the documentation, and it is worth reading before you submit rather than after.
- A place to keep per-company identifiers
- Customer, product and ledger account IDs differ from one Pennylane company to the next, and its ledger accounts follow the French chart of accounts. Store them per connected company, because the same product carries a different ID for every customer you connect.
- A schedule, and a window it has to stay inside
- Change detection is a read you run on an interval. Pennylane keeps its change history for four weeks and refuses to look further back, so an integration that goes quiet for longer needs a full comparison rather than a catch-up.
We walk through the credential and the partner step with you.
One shape for Pennylane, and for the system after it
Pennylane keeps its books on the French chart of accounts, and its identifiers differ from one connected company to the next. A shared shape is what keeps both of those out of the code you write.
Everything readable is also writable, and nothing updates
Customers and suppliers are enabled in both directions. Updates in place are not: you can create a supplier and there is no enabled path to change it afterwards, so plan corrections before you plan the first write.
The scope list is wider than what is switched on
The client you register with Pennylane carries eleven scopes, from invoices to the ledger. Customers and suppliers are what is enabled through Maesn today, and the rest of that list is available on request, so tell us which objects your use case needs.
No object deletes by default
No object has delete enabled. Accounting practice expects corrections and cancellations as new documents anyway, so plan them that way rather than around a delete you would have to request.
Whatever the connection carries comes back in the shared common data model, so a contact from Pennylane has the same shape as a contact from a system ten times its size, and the code you write here is the code you reuse for the next one.
The ceiling is worth designing for rather than discovering. Pennylane allows 25 requests every 5 seconds per token across every endpoint, and a single invoice takes several calls to assemble, so a bulk job meets the limit long before a single sync does. When it does, the 429 arrives with the headers that say when to come back, and one error contract is what keeps that from being a Pennylane-shaped branch in your code.
Tell us which objects your use case needs and we will confirm what is possible.
