Most people who use Flipsnack never need to think about the API. They upload a PDF, add some interactivity, share a link, and that is the whole workflow.
But there is a point where that stops being enough. When you are managing hundreds of documents. When your content lives in one system and your published flipbooks live in another, and keeping them in sync means someone on your team has to do the same update twice. When you need Flipsnack to do its job inside a platform your users are already in, without them ever visiting Flipsnack directly.
That is what the API is for. It is a connection between Flipsnack and whatever system your team already uses. Once your tech team sets it up, the publishing side mostly takes care of itself.
This article explains what the API actually does, through the lens of how real teams have described needing it.
Your team, or the people using your platform, are already uploading PDFs somewhere. On your website, in an internal portal, inside another tool. And right now, someone has to separately log into Flipsnack to convert and publish each one.
A company that runs a curriculum platform described exactly this. Contributors uploaded educational materials to their website. The goal was that the moment a PDF was uploaded, it should appear as an interactive flipbook on the page. No extra step, no Flipsnack login, nothing for the uploader to do. “Preferably it could be like an onsite thing. Upload the PDF and then the PDF gets sent to Flipsnack. And then yeah, it gets automatically converted into a nice little book.”
Your platform sends the PDF to Flipsnack, Flipsnack converts it, and sends back the embed code. The flipbook appears on your page. Nobody from your team has to touch Flipsnack directly.
It works for any situation where PDFs are coming in from outside and need to become flipbooks without a person in the middle. The API handles files up to 500 MB and 1,000 pages per document, and all requests are verified using MD5 signature authentication. If you want to see exactly how the conversion works, the create a flipbook endpoint is a good place to start.
Publishing is rarely the end of it. Prices change. Schedules shift. A product gets discontinued. A policy gets updated. Every time that happens in your source system, someone has to open Flipsnack and make the same change there too.
When you have a handful of documents that rarely change, that is fine. When you have hundreds of products updated regularly, or content that needs to reflect live data at all times, it is not.
A travel company described their version of this. Their reps shared custom trip plans with clients as flipbooks. When a hotel changed or an itinerary shifted in their back-end system, the flipbook the client had was already wrong. What they needed was straightforward: “The sync piece, so that if somebody pulls a new itinerary after the change, they would get the change automatically.”
The API makes this possible. Your source system, whether that is a CMS, an ERP, a PIM, or any other platform where your content actually lives, pushes updates to Flipsnack when something changes. The published flipbook reflects those updates straight away for anyone who has the link. No re-publishing, no new link to send out, no one on your team making manual edits. The update endpoint handles this.
One salesperson described the principle from the catalog side: “You don’t need to export spreadsheets and then import them into Flipsnack. Whenever you have any updates, you just make updates in your system and then you reflect that into Flipsnack.” Price changes, new SKUs, updated images. It all flows through automatically once the connection is in place. The product sync endpoint handles individual product data.
Some teams do not want their people logging into Flipsnack at all. They want it to sit in the background of a workflow that already exists, receiving content, converting it, and handing back a link or an embed code for the rest of the process to use.
One company ran their proposals through PandaDoc. When a proposal was finalised, it came out as a PDF. They wanted that PDF to automatically become a flipbook, with the link landing inside a Salesforce email to the client. All without anyone visiting Flipsnack. The API handled it: “We receive the PDF, convert it into a flipbook, and then respond with the link that you can share.”
A printing company used it differently. They offered customers a preview of their printed materials before anything went to press. The API generated the preview on the fly inside their own platform, with no sign of Flipsnack visible to the customer.
In both cases, Flipsnack becomes a service your platform calls rather than a tool your team logs into. It receives something, does something with it, and gives something back. Your users never need to know what is running in the background. You can see the full embed code flow in the get embed endpoint documentation, or try the live API demo to see it in action.
For most teams, Flipsnack hosts the flipbooks and you embed them on your site via an iframe. Any changes you make in Flipsnack appear automatically wherever the flipbook is embedded, and you get statistics throughout.
For some organisations, that setup does not work. Their IT or legal team requires that content be served from their own servers. They cannot have a dependency on an external hosting provider, or they need to meet specific data governance requirements about where documents live.
The API’s HTML5 export lets you download a self-contained package of any flipbook. Your tech team hosts it on your own infrastructure. The reading experience, the page-turning, interactivity, accessibility features, works exactly as it does when Flipsnack hosts it, just from your own servers. The HTML5 export endpoint covers exactly how to generate and download the package.
Once a flipbook is hosted as a static HTML5 package, it is fixed. If you update the document in Flipsnack after that point, those changes will not appear on your site. For content that is live and regularly updated, the standard embed is the better option. For fixed content, a published annual report, a signed agreement, an archived edition, self-hosting makes sense.
Flipsnack gives you statistics for every flipbook: views, time per page, link and button clicks, geographic breakdown, lead form submissions. For most teams, the built-in dashboard is enough.
For teams running larger content operations where reporting lives somewhere else, an internal dashboard, a business intelligence tool, a CRM, the API lets you pull that data directly. No logging into Flipsnack, no manual CSV exports, no copying numbers from one platform to another.
The per-flipbook stats endpoint returns reading data for a single publication, and the account-level stats endpoint aggregates across everything. Feed that into whatever system your team already uses for reporting, on any schedule, without any manual step.
For teams capturing leads through flipbook forms, the contact form webhook pushes submissions straight to HubSpot, Salesforce, or any Zapier-connected tool the moment someone fills in a form. No one has to check the Flipsnack stats page to know a lead came in. And for B2B teams using the shopping list, the order webhook does the same. The moment a buyer submits an order from a flipbook, it goes wherever it needs to go.
There is a category of document that is not one version for everyone, but a different version for each person. Sales proposals tailored to each client. Benefit guides with each employee’s specific plan details. Onboarding materials adjusted for each new hire. Partner presentations with the recipient’s data filled in throughout.
Done manually, one of these per person is an afternoon. A hundred is a project. Five hundred is a problem that does not get solved, it just gets delayed.
The API treats document creation as a repeatable process. You build the template once, the design, the layout, the fields that will vary. The API populates each version with the right data and hands back the corresponding link or embed code. One template, as many personalised documents as you need, with no manual work after the initial setup.
A financial services team described wanting exactly this for client reporting: a single template that would pull different data for each of their clients, producing an individual document for each one. “Is there a systematic way to load data for a specific template but for 500 people, each with different information?” That is the use case the API is built for. The product create and product update endpoints handle the data side of this.
The API requires development time to set up. That comes up in almost every conversation about it, and it is worth being straight about.
How much time the setup takes depends on what you are building. Connecting a CSV export from your ERP to Flipsnack is a straightforward integration. “Usually the tech team looks over the documentation and gives you a rough estimate of what it would entail on your end.” Building a fully automated pipeline where PDFs from another platform are converted, configured, and served back with embed codes is more involved.
Most teams start by getting the documentation in front of whoever handles their technical side, whether that is an in-house IT team, an external developer, or a single person who manages the tech. From there, they can give a realistic read on complexity and timeline. The live demo is also worth passing on, since it shows the full conversion and embed flow running in a real environment.
Files up to 500 MB and 1,000 pages are supported per document. All requests are authenticated via MD5 signature. Your tech team will need to generate API keys from the Flipsnack Integrations dashboard once your Enterprise plan is active. Flipsnack’s customer success team is available for technical questions during and after setup.
Custom API development is also available if your use case does not fit the standard endpoints. One team’s needs required adapting the API to their specific setup: “We needed to work on the API to adapt it to their needs. Sometimes that’s the direction we go.”
The API is the right choice when one of these is true.
Manual work does not scale at your volume
Teams generating tens of documents a week, hundreds a month, or thousands a year are the natural fit. Teams currently using the API manage over 20,000 documents per customer, auto-publish more than 2,000 active listings, and automate over 300 documents a year per team.
Your content lives somewhere else and needs to stay connected
If the source of truth for your content is a CMS, an ERP, a PIM, or any other system, and you want your flipbooks to reflect changes in that system automatically, the API is what makes that connection permanent.
You need Flipsnack to be invisible to your users
If you are building something where your users upload files, access personalised documents, or see previews, all through your own platform, the API lets you offer that without exposing Flipsnack as the tool behind it.
Your reporting lives outside Flipsnack
If you manage a large content operation and your analytics need to feed into internal dashboards or a CRM, pulling data via the API removes the manual export step entirely.
If none of those apply and you are uploading PDFs and sharing links one at a time, the standard Flipsnack plans are what you need. The API is for when the process itself needs to be connected, automated, or embedded into something bigger. If you think you are in that category, the best next step is talking to our team or reading through the documentation, whichever feels more useful right now.
Talk to our team and we can help you figure out which connection makes the most sense for your workflow, whether that is the API, a spreadsheet sync, or a direct CRM integration.
Yes. The API is a technical integration that requires someone on your team to write code and connect the two systems. That person could be an in-house developer, an external IT contractor, or an agency. Flipsnack provides detailed documentation and your customer success manager will guide your team through the setup. If your team is not technical, the CSV or Google Sheets sync options can achieve many of the same outcomes without any development work.
API access is available exclusively on the Enterprise plan. Once your plan is active, you generate API keys directly from the Integrations dashboard inside your account. If you are on a lower plan and want to explore upgrading, you can contact the sales team to discuss your requirements and get a quote.
It depends on what you are building. A straightforward connection, like converting PDFs uploaded to your website into flipbooks, can take a developer a few days once they have reviewed the documentation. More complex workflows, like a fully automated pipeline connecting an ERP to Flipsnack and serving embed codes back to another platform, will take longer. Most teams pass the documentation to their technical person first and ask for a rough estimate before committing to anything.
Yes. Flipsnack offers custom API development for teams whose use case does not fit the standard endpoints. This is scoped and priced separately from the subscription. One team needed their preview generation system connected in a specific way and Flipsnack’s team worked with them to adapt the API accordingly. If you have a non-standard workflow, the best starting point is a conversation with the sales team to see what is feasible.
The API supports individual files up to 500 MB and up to 1,000 pages per document. This covers the vast majority of use cases, including large technical manuals and high-volume retail catalogs.
Yes. Every request to the Flipsnack API is authenticated using a unique MD5 signature, which ensures that only your authorised systems can access, manage, or modify your content. Flipsnack’s platform is hosted on AWS and meets enterprise-grade security standards including SOC 2 compliance. Security documentation is available on request for IT and legal reviews.
This site uses cookies to improve your online experience, allow you to share content on social media, measure traffic to this website and display customised ads based on your browsing activity.
Privacy Policy