Scopes define what resources an application can access via an API. In OAuth 2.0, they manage permissions and enhance security. As part of your onboarding, we will determine the appropriate scope for your business.

Usage of Scopes

1. Access Control: Limit access to resources, e.g., FUSESIGN:OWN.

2. Granularity: Offer different access levels.

3. Authorization: Users consent to requested scopes.

4. Token Enforcement: Tokens carry scopes to restrict access.

Scopes ensure applications request only necessary permissions, improving security and user trust.

Available Scopes

FuseSign has the following available Scopes

Authorization

Users must authorize integrations to be allowed into their account This is how that will appear:

Webhooks are advantageous for their ability to facilitate real-time communication between applications:

• Instant Notifications: Webhooks allow your application to receive real-time data updates without polling the server repeatedly. This ensures timely updates.

• Resource Efficiency: Unlike traditional APIs that require constant checking for updates, webhooks only send data when an event occurs, reducing resource consumption.

• Automated Workflows: By triggering specific actions based on events, webhooks enable seamless integration between systems, allowing for automated workflows and enhanced productivity.

• Scalability: As your application grows, webhooks can efficiently handle increased event loads, ensuring consistent performance and user experience.

Webhook Structure

The webhook event structure is of type TransactionalBundleWebhookPayload:

Webhook Events List

Webhook Setup

When a bundle is created via specify Settings > WebhookUrl in the payload:

Webhook authentication

All webhooks will be sent with your developer specific Fuse-Signature header. This header can be used to verify the message was sent via the FuseSign API. The header can be found on your developer listing page.

Webhook retry logic

FuseSign webhook's will automatically retry if no 200 response is received.

The system will retry up to 5 times with the following back-off logic:

• 1st retry – after 30 minutes

• 2nd retry – 60 minutes thereafter

• 3rd retry – 120 minutes thereafter

• 4th retry – 120 minutes thereafter

If the 5th and final retry is unsuccessful, a permanent webhook failure is registered in our system – if these are frequent, we’ll get in touch :)

An example workflow for signing documents

1. Register via OAuth for the target user - retrieve their Tenant Id via /api/Tenant/List

2. Upload document(s) via the /api/Document/Upload endpoint.

   • Record the ID(s) of the uploaded documents.

3. Create a new bundle via the endpoint.

   • Register your callback WebhookUrl for that specific bundle.

   • Note: Certain authentication methods require customer details. E.g. SMStoSign requires the mobile number to be uploaded on customer creation.

4. The signing customer opens and signs the documents via the FuseSign platform.

   • Receive and react to webhook events. [Customer opened, customer signed, bundle finalised etc]

5. Once all documents are signed and the bundle is finalised - retrieve the bundle via - This will confirm the status and include the Document Ids to be used in and also included in the SignedPDFDownloadUrl attribute per document.

6. Once documents are downloaded - Archive the bundle via (This will be done in 60 days automatically once the signed document download has been registered, don't worry we'll keep reminding you via webhooks :) )

Authentication

To get started you will need a developer account. Please contact to arrange a test account.

There are two main methods of authentication:

1. Tenant token - Uses Bearer OAuth2 to login on behalf of an existing FuseSign user. [MOST COMMON].

   • This will include a ClientId and ClientSecret (see workflow below)

   Please note that HTTP request header is required when making a OAuth Post call, which needs to be sent as application/json type.

2. Wholesale token

All operations require a wholesale token (or OAuth2 bearer access token) and a TenantId.

OAuth 2 Register Method

Step 1 - End user redirection

HTTP GET

• response_type with the value code

• client_id with the client identifier

• redirect_uri with the client redirect URI. This parameter must match the registered redirect domain below.

Response

• code with the authorization code

• state with the state parameter sent in the original request. You should compare this value with the value stored in the user's session to ensure the authorization code obtained is in response to requests made by this client rather than another client application.

Step 2 - Get Token

HTTP POST

• grant_type with the value of authorization_code

• client_id with the client identifier

• client_secret with the client secret

Response

• token_type this will be the word Bearer (to indicate a bearer token)

• expires_in a date time offset representing the TTL of the access token (i.e. when the token will expire)

• access_token the access token itself

Step 3 - Refresh Token

HTTP POST

• grant_type with the text value refresh_token

• refresh_token with the refresh token

• client_id with the the client's ID

Response

• token_type this will be the word Bearer (to indicate a bearer token)

• expires_in a date time offset representing the TTL of the access token (i.e. when the token will expire)

• access_token the access token itself

Step 4 - Revoke Token (at end of life)

HTTP POST

• refresh_token with the refresh token

• client_id with the the client's ID

Response

Http 200 if successful

Wholesale token Method

This method is much simpler - all calls are made with X-API-Token in the header. This Token is tied to a specific user with account privileges. I.e. over a single tenant. For more information or to discuss your use case please contact

Example: Bundle Create

The basic use case for a Bundle is to use the endpoint

A simple example payload is:

There are many more options available to this object, see below for the full specifications. Configuration available:

• Set a Metadata for any document, client or bundle for retrieval and search.

• Upload a document via Base64 content or via File upload (via )

• Change the ViewMode: Available SmsToView, SmsToSign, EmailToSign, EmailToView

When a bundle is created. It is sent off for digital signing and can be also assigned view actions.

FuseSign offers two different modes for document signing: Sign Entire Document and Signature Placeholders.

The property SigningMode is optional, which can be set to SignWhole or SignPlacements. We recommend being explicit by adding this parameter.

SigningMode defaults to SignWhole when not included in the request body but will use SignPlacements if set in the business settings.

Signature Placeholders mode requires CustomerInputElements against each Documents of the payload.

Both methods of signing include a true digital signature using computer technology to authenticate the signature by way of attaching a transcript and embedding a digital certificate validating who signed the documents and protecting the information from tampering.

Sign Entire Document Mode

Sign Entire Document means that visual signature images will not be placed on specific locations in the documents. This method significantly reduces the complexity of creating and sending bundles. The signer is effectively agreeing to approving and digitally signing the entire document and the contents contained within the document. They agree to the terms of digital signing by agreeing to the terms when they sign.

FuseSign will place the signers' initials on each page of the document if this option is enabled in your (Settings > Document Output > Signers' Initials Position) . The initials will be placed on each page of the entire bundle and cannot be toggled on a bundle basis.

Signature Placeholders Mode

Signature Placeholders means that when preparing a bundle, the user will add a ‘signature placeholder’ to assign each of the specific locations within the documents where your recipients' signature will visually appear.

This method does not include signers' initials on each page, even if this option is enabled in business settings.

Signature Placement Type

If a recipient has a signing action on a document, at least one of these placeholders will be required. When your recipient signs, their signature will appear on the document where you place these.

Signature Placements

• Standard - Adds a standard signature placeholder to the document

• WithDate - Similar to the above, but also automatically adds the signing date below the signature

User Inputs

These options allow your users to fill out additional information on your document. You can also set properties for these inputs from the right panel to make them mandatory, or to assign a default value.

• TextLine - Adds a single text line for your recipient to fill in

• CheckBox - Adds a checkbox to the document, that can be checked by the recipient

• Date - Allows your recipient to manually fill in a date

Signature Stamps

These stamps do not require any interaction from your recipient and will be automatically filled when the document is finalised.

• SignedDate - Automatically stamps the date the document was signed by this recipient.

• SignerName - Automatically stamps the signer’s name

PlacementType

Placement type is another property of CustomerInputElements . There are two options for placement:

ByCoordinate (for static documents)

If the documents you are sending from your API are the same every time, we recommend this mode.

It uses X, Y, W and H to set the dimensions of the placeholder. (X / Y is the co-ordinate from the top left of the page)

ByAnchorText (for dynamic documents)

If the documents in dynamic and you require placeholders in different locations we recommend this mode.

Specify AnchorText to have the display over the text found.

Tips for AnchorText

• Use a special / unique word without any special characters

• Keep it short and simple but not a subset of other words

• Should be hidden by having the colour match the background. Ie. white.

You can also specify the AnchorFindCountthat is the number of instances being placed (0 = unlimited)

Pending Documents

When documents are uploaded via the Document Upload endpoint they exist in a Pending state until they are linked to a bundle via the Bundle Create endpoint.

Pending documents are removed every 24 hours.

You can list any pending documents via the /api/Document/ListPending endpoint.

Base64 Uploads

The Base64 content option in the Bundle Create endpoint should only be used in limited scenarios. Because all Base64-encoded documents are included directly in the payload, this approach significantly restricts the maximum file size that can be uploaded.

Instead, we recommend using the /api/Document/Upload endpoint to upload documents. Once uploaded, include the returned DocumentId in the Bundle Create payload. This approach avoids payload size limitations and is the preferred method for handling document uploads.

We work closely with software companies, platforms, and developers to create deep integrations that enhance workflow automation for mutual clients. But our bread and butter is sending documents for signing!

Integration Types

We have two primary integration types depending on who you are.

a) Product Integration

• This is another piece of software pushing or pulling information into FuseSign.

b) Private integration into a FuseSign account

• This is typically a large firm that wants to automate processes

How we work with Application Partners

• Intro Call & Use Case Review Let’s understand your platform and your clients’ needs.

• Tech Alignment Call We’ll provide API documentation and sample use cases to validate technical feasibility. Following this we will provide access keys to our production environment with a test developer account loaded with some credits!

• Integration Build You develop the integration with guidance from our technical team as needed. Your account is placed InReview mode which places a watermark on documents you send for signing. Read more below, .

In Review Mode

To get the best signing experience possible and to ensure proper performance we place a watermark on all bundle documents sent for signing from a developer InReview . All other functionality is the same!

What happens on the review call

Review of Use Case Alignment

To get InReview toggled off we need to see demonstration over video call, or recording of the signing flow:

Questions to expect

Please prepare responses for the following questions:

• How does your integration handle two people with the same email?

• How do you cancel an active bundle?

• How do you remind participants of an active bundle?

• What happens when a signer rejects a single document?

Notes for Production Use

• Confirm that any applicable URLs for uploads are whitelisted.

Final Decision and Account Upgrade

• Once all above criteria are met, we will remove the watermark from documents generated by the developer's integration and you're ready for production usage!

For more information email us at .

Welcome to the FuseSign API

This API Allows you to interact with the FuseSign platform to send out signing bundles.

For more information on FuseSign please see https://fusesign.com or developersupport@fuse.work. To interact with API using postman, we suggest following the process of importing swagger into postman using the public swagger.json

Key Features

• OAuth2 or fixed header authentication.

• GUIDs everywhere! (tenants, bundles, documents, customers, webhooks)

• Webhooks for any events on a sent document bundle.

• Metadata can be attached to objects to allow reference back to an external API.

Special Cases

• Creating a Draft: To create a bundle as a draft, Set the CreationMode to CreateAsDraft.

  • This will populate the DraftUrl on the response bundle which can be used to review and send the bundle.

• No FuseSign Emails: To disable FuseSign emails Set the Bundle -> Settings -> EmailPreference to NoFuseSignEmails.

Any questions please don't hesitate to contact us at .