QUICKSTART
Open your first document.
The shortest path from an empty web app to a rendered Office document: load the SDK surface, supply a file source, and confirm the open event end to end.
DOCUMENTATION
Start integrating with the right document.
The documentation set covers the whole integration path: embed the editor surface, connect your backend through callbacks, validate formats, and deploy on your own infrastructure. Start with the quickstart, then follow the surface you are building first.
OFFICE SDK / DOCUMENTATION
12345
ILLUSTRATIVE SAMPLE / OFFICE WORKFLOW
Keep the file
with the work.
A sample Office surface for products that keep a document beside the work around it.
Illustrative sample
Product context → Office surface → business result
A CLEAR BOUNDARY
Useful detail for the next technical question.
Use these pages to decide which workflow, format, and ownership boundary should be validated first.
Your system keeps file storage and permissions.
Preview, edit, review, import, and export are separate decisions.
Callbacks and SDK surfaces connect the document to your product.
FRONTEND EMBED
Place the editor inside your product.
Mount the document surface in the page, size it to your layout, and choose preview, edit, or review per view. The surface receives context; your product keeps identity and permissions.
BACKEND CALLBACKS
Connect saves to your system of record.
Callback endpoints let your backend issue access decisions and receive saved results, so storage and versioning stay in the system you already operate.
DEPLOYMENT
Run it on your infrastructure.
Self-hosted deployment guidance covers the Ubuntu baseline, single-server proof of concept, and the production readiness checks your team should record.
Office SDK documentation maps the integration path from first open to production deployment: frontend embed, backend callbacks, format validation, and self-hosted operations.
4 areas:
documentation set
Quickstart, frontend embed, backend callbacks, and deployment form the core reading path.
2 sides:
integration boundary
The browser surface and your backend meet through defined context and callback contracts.
1 rule:
validation first
Every guide asks you to confirm the behavior with your own files before production.
COMPARE THE BOUNDARY
Find the document by the next question
| Your question | Start with | You leave with |
|---|---|---|
| Does the file open in our app? | Quickstart | A rendered document and a verified open path |
| Where do saves go? | Backend callbacks | A save flow that lands in your storage with version identity |
| What does the server need? | Deployment | A sizing and environment plan for your infrastructure |
| Which formats behave how? | Formats page | An operation-by-format validation checklist |
Read by the question you are answering
Pick the document that matches the decision in front of you. If the question is whether the file opens correctly, start with the quickstart. If the question is where a saved version lands, read the callback guide. If the question is what the server needs, start with deployment. Reading in this order keeps each check tied to one decision.
Keep the boundary in the notes
While integrating, record which system issued the access decision, which system stored the result, and which version identifier the business record points to. These three facts resolve most later questions about a document without reopening the editor.
APPLY THE GUIDANCE
Four checks before the next decision.
- Open the quickstart and render one of your own files.
- Decide which view is preview, which is edit, and which is review.
- Wire the callback endpoint and save one document into your storage.
- Record the version and access decision with your business record.
RELATED STANDARDS AND CONTEXT