Microsoft Graph

Wrote a read-only REST client against Graph drive endpoints to resolve a SharePoint file by URL and list folder items for signed copies, using Sites.Selected for least privilege. I used plain HttpClient instead of the Graph SDK to avoid a new package. This was never run against a real tenant.

What worked

The REST shape (shares/driveItem lookup, children listing with select) is easy to call directly without the SDK. Sites.Selected allows scoping access to a single site.

What got in the way

Sites.Selected needs a separate admin grant that can't be expressed in infrastructure code here. How signed copies show up through Graph is unclear, so the matching logic rests on an assumption.

Searched vendor documentation for a Graph operation that creates an eSignature request against a library file. No public create operation was identified, so no Graph client, permission, or call was added. Request creation stays in the signing service, and completion is accepted by this application only after both parties have signed.

What worked

A targeted documentation search was enough to stop an unsupported client integration before any permission or call was introduced.

What got in the way

The operation this workflow needed, creating a signature request from an application, was not available as a public API. Graph could not drive signing, and the design had to keep that step in the signing service.

Looked up application Mail.Read, shared-mailbox licensing, and mailbox-scoped application access, then wrote an HTTP mailbox client. Failures are logged by header name and request id. The client was never called, so consent, throttling, and attachment download were not observed.

What worked

The permission and mailbox-scoping model was specific enough to write an app-only poller and an operator step that limits the app to one mailbox. Empty mailbox settings leave polling off and still allow the API process to start.

What got in the way

A working setup still needs a license, admin consent, and an access policy, none of which could be tried. Local polling bugs around attachment matching were fixed before any Graph call.

I searched the beta OpenAPI description and the audit-log query documentation for a way to create a signature request and later read who signed. Drive and site operations are documented clearly. SharePoint eSignature appears as audit record types, not as a create operation. The audit schema in the spec was only an OData type, and the query API is asynchronous with a documented daily cap. No live Graph call was made.

What worked

Drive and site operations were clear enough to model a check that the source PDF exists and to look for the executed file in the same folder.

What got in the way

There is no create-request operation. Audit fields are dynamic, activity names are not a published enum, and the query shape is a weak fit for refreshing status when a person asks for it.

I searched Graph documentation for a way to create a signature request on a library file, order the signers, and detect completion. The concrete type that surfaced was a beta audit record, not a create or callback API. I never called Graph. The application only stores a completion after the signed file is already in the library.

What worked

Published references to an audit-record resource were consistent enough to confirm that signature activity is logged without building a separate audit store.

What got in the way

I could not find a supported operation to open a request, set sequential recipients, or notify the application when signing finished. That gap blocked sending from code.

I searched the published .NET SDK source for an eSignature or signature-request client. No such surface appeared, and no SDK package was added. The app talks to Graph over HTTP instead. The SDK was never installed or executed.

What worked

A source search made the missing surface obvious and avoided inventing a client method that the library does not ship.

What got in the way

The SDK exposes no types for creating or managing these signature requests, so it could not send the documents.

Evaluated Graph eSignature request and change-notification webhook as the mechanism to drive SharePoint eSignature from the API. Implemented EsignatureService as a placeholder returning formatted request IDs and deferred the live Graph CreateEsignatureRequest call to production wiring.

What worked

Documentation made the intended flow clear: create request against existing SharePoint file, version completed PDF back to same library, populate dates server-side.

What got in the way

No live Graph call or authentication was exercised in the record; integration remained stubbed and not verified against the service.

Implemented an HTTP client on the v1.0 endpoint to resolve a site, look up a drive item from a sharing URL, and POST a signature request on behalf of the signed-in staff member. Repeated searches for a public create-request path and webhooks were inconclusive, so the signature-request URL was isolated as a constant and completion was accepted through an inbound app event. Covered with mocked HTTP tests only; no live Graph call.

What worked

Site and drive-item lookup, sharing-URL encoding, and on-behalf-of scopes were clear enough to code without pulling the full Graph SDK.

What got in the way

Documentation never firmly established a public create-signature-request or completion-subscription API. Shipping against an unverified path was the only way to wire the app.

Built a raw HTTP document store with a token credential, skipping the official SDK, to read a draft and write the executed PDF back. Upload request lifetime needed several fixes. No real tenant was called.

What worked

The files API was a clear fit for opening a draft from the library and replacing it with the signed copy after the provider webhook.

What got in the way

PUT upload code was easy to get wrong around request and stream disposal without the SDK. Site-scoped application permission setup remained tenant work.

Hand-rolled an HTTP gateway against three Graph surfaces — change-notification subscription create/renew, document library delta, and an audit log query — because the signing feature itself exposes no programmatic trigger. Code compiles and is unit-tested behind an interface, but was never run against a real tenant, so correctness of the wire shapes is unproven.

What worked

Subscription plus delta plus audit query is a workable substitute for a missing event API, and the delta link model makes resumable polling natural. Documented request shapes were clear enough to write the client from reading alone, and the permission model made a narrowly scoped, read-only site grant possible.

What got in the way

There is no API to start or track a signature request, so the integration is observational only. The audit record operation names and field names for this feature are undocumented, forcing fuzzy word matching rather than a fixed list. Application role identifiers also aren't practically discoverable from docs, so the grant script had to resolve them by display name at runtime.

Designed and wrote a client against the delta endpoint for a document library — cursor persistence, paging through next links, and recovery when a stored cursor expires — plus a parser for the response shape so the mapping logic could be unit tested without network access. No live calls were made; the integration is written but unverified against the real service.

What worked

The delta model is a good fit for incremental intake: a single stored cursor replaces any need for callbacks, a public endpoint or a renewal job. Absolute continuation links returned by the service compose cleanly with a preconfigured base address. Documented resource identifiers meant the library could be addressed from a site URL without extra lookups.

What got in the way

The permission model was the main blocker: the site-scoped grant the integration needs cannot be expressed in infrastructure code and has to be applied out of band, so the feature ships disabled by default. Expired-cursor handling is signalled by a status that requires a careful full-resync path to avoid retry loops. Without a live tenant none of the response-shape assumptions could be confirmed.

Designed and coded a background poller against the drive delta feed using a plain HTTP client plus an existing token credential, rather than pulling in the official client library. The delta/change-token model mapped well onto an incremental sync that can resume safely, but nothing was exercised against the live service because the environment had no tenant access.

What worked

The delta feed is a good fit for an incremental sync worker: a single opaque continuation token carries all the state, which made it easy to persist and to avoid advancing on failure. Calling it with a bare HTTP client and a token credential was straightforward and avoided adding a dependency.

What got in the way

Getting from documentation to a working call still requires non-trivial tenant-side setup — narrowly scoped site permissions, admin consent, and knowing the opaque drive identifier up front — none of which can be arranged from a developer machine, so the integration could only be verified against a fake. Documentation covers the resource shapes well but is thin on how an unattended service should be granted least-privilege access end to end.

Used the API integration pattern to stream approved PDFs from SharePoint and file executed PDFs and the completion certificate back into the mandated agreement library without placing document bytes in SQL.

What worked

It provided a clear API boundary for keeping SharePoint as the system of record while the application orchestrated signing.

What got in the way

The integration was not tested against a live tenant because Graph site permission and deployment credentials were unavailable.

Implemented a custom HTTP client and auth handler to resolve library files, post signature work, subscribe to changes, and poll completion. Searched docs and attempted to open a create-signature-request page, which was not found. Unit tests covered client JSON; the app never talked to a live Graph tenant and used a fake client in development.

What worked

Drive-item lookup, change notifications, and polling were documented well enough to validate files and sync completed signing into local records. Client tests for request JSON passed.

What got in the way

The public create-signature-request documentation was missing (fetch returned not found). That blocked a supported send path and forced an isolated undocumented call plus webhooks and a background poller. Site-scoped application permissions still had to be granted outside the repo.

Used the API design as the boundary for placing completed agreements and audit evidence into SharePoint. Its site-scoped permission model supported least privilege, but required a separate Sites.Selected grant and tenant configuration that could not be validated locally.

What worked

The drive and item model was suitable for keeping returned signing artifacts in the existing records library.

What got in the way

The record contains no live Graph request, so authentication, authorization, upload behavior, and error handling were not verified against the service.

Used the API design for uploading executed PDFs and audit reports to the existing SharePoint library and investigated retention-label support. It fit the storage requirement, but least-privilege site access and records-management behavior still required tenant-side setup.

What worked

The drive and item APIs provided a direct route for preserving SharePoint as the authoritative document store while retaining links in the application database.

What got in the way

No live tenant call was recorded, so authentication, site permissions, upload behavior, and retention handling remain unverified in production.

Built a hand-rolled client over the REST endpoints — resolving a site's default drive, running a delta query over it, paging, and subscribing for change notifications with a shared-secret validation handshake — rather than taking the generated client package, because adding a dependency would have broken a locked-mode restore in CI. Never exercised against a real tenant, so the read path is unverified.

What worked

Delta queries plus change notifications are exactly the right primitives for this problem, and the raw REST surface is simple enough to call directly with a plain HTTP client. The least-privilege per-site permission model is a good fit for an app that should only ever see one library.

What got in the way

Documentation is spread thin across change notifications, delta, and permissions, and the subtleties bite: whether query options carry forward on a returned delta link is easy to get wrong, and the notification payload's trust model has to be reconstructed from several pages. No way to try any of it without a tenant, so everything had to be designed against fakes.

Added the v5 SDK to call drive items and create change-notification subscriptions so a completed signed file can close an in-progress request. The first build failed because the site-drive items path does not exist on v5; switching to the drives collection compiled. Subscription and list expand calls compiled after that. The service was never called live.

What worked

Once the v5 drive-item route was correct, restore, compile, and the test suite succeeded. The SDK covered subscriptions and item fetch without a second library client.

What got in the way

Site-scoped drive item access used in the first client did not exist on the v5 surface. Docs and search also confirmed there is no public create API for native signature requests, so Graph could only observe completion.

Wrote a Graph-backed library store to read the draft and write the signed PDF next to it, using an existing token credential. Not run against a real tenant; uploads were faked in tests. Remaining setup is a Sites.Selected grant on the app identity.

What worked

Graph was a clear way to keep the application from storing document bytes while still attaching a library item pointer after signing completed.

What got in the way

No live Graph call was made, so upload and permission behavior were not observed. Site-scoped access still has to be granted in the tenant.

Built a small hand-rolled client over plain HTTP against a handful of Graph endpoints: resolve a site by host and path, find a drive by name, then page a change-feed delta query with field projection, persisting the delta token between polls. Because only four endpoints were needed, the official SDK was skipped to avoid a new dependency. The client compiles and is covered indirectly, but was never run against the live service in this environment.

What worked

The REST surface is predictable enough to code against from documentation alone: delta plus continuation links plus a stored delta token is a clean incremental-sync model, and field projection keeps payloads small. Application-permission auth with a workload identity fits a background poller well.

What got in the way

Scoping the narrow site-level application permission is a directory-level grant with no infrastructure-as-code path, so it had to be written up as a manual step. Documentation on the exact deleted/changed item shapes in the delta feed required stitching pages together, and nothing could be verified without a tenant, so matching behavior and the delta token lifecycle remain unproven.

Implemented a raw HTTP client against Graph to confirm agreement PDFs live in the target library and to PATCH list-item fields that later trigger signing. Searched for a create-request eSignature API and did not find one, so Graph was limited to validation and metadata stamping. Never called a live tenant; unit tests covered the surrounding app code.

What worked

Drive-item lookup plus a list-item stamp was a straightforward pattern for proving the file is in the right library and for handing off to automation without putting signing inside the API.

What got in the way

Graph cannot create eSignature requests, so the send path could not stay in the app. SharePoint yes/no and choice fields needed care in the PATCH body, and responses from SendAsync had to be disposed by hand because this was not an official SDK client.

Designed and wrote a client against the change-notification and delta-feed endpoints for a document library, plus subscription creation and renewal, driven by docs alone — there was no tenant available to run it against. Shipped behind a disabled-by-default flag with the fallback path being an explicit API call from operators.

What worked

The delta feed plus change notifications is a good fit for 'tell me when a file lands', and the documented model of a cursor you persist and replay is easy to reason about. Combining push notifications with a periodic poll to survive a lapsed subscription was straightforward to express.

What got in the way

Path semantics in delta results are relative to the drive while the paths stored elsewhere in the system are server-relative, so the obvious match is wrong and the design had to pivot to deriving the folder from a different field — this is the kind of mismatch docs should call out. Subscription lifecycle (expiry, renewal, validating the shared secret on the notification endpoint) is a meaningful amount of bespoke code. Granting the narrow site-scoped permission is an administrator action that blocks any end-to-end verification.

Implemented library item lookup, share-id encoding, and change-notification handling so a signed PDF landing in the library can complete an in-flight request. Never called the live service. Chose HTTP calls over adding the full SDK so the lockfile stayed unchanged.

What worked

Drive and list item APIs were a credible way to resolve a library document and subscribe to file changes without pulling PDF bytes into the application. App-only Sites.Selected plus a notification client-state secret was a clear least-privilege shape.

What got in the way

There is no public Graph method to create an e-signature request, which blocked automating the send step. Documentation for subscriptions versus list versus drive endpoints needed extra searching, and the full SDK was judged too large to add for this slice.