Skip to content
Skills Library
Programming · Building & coding

procore-sdk-patterns

/procore-sdk-patterns

Design a thin Procore REST client that preserves endpoint-specific versions, company routing, pagination links, errors, and rate headers. Use when building or reviewing a shared HTTP adapter instead of copying ad hoc requests. Trigger with: "build a Procore client", "review Procore SDK patterns", "standardize Procore API calls".

Licence
MIT
Last repository change
26.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
2
Scripts
0
HTML comments
0
URLs in SKILL.md
3
Deprecation

No signals detected. Repository changed on 26.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Design a thin Procore REST client that preserves endpoint-specific versions, company routing, pagination links, errors, and rate headers. Use when building or reviewing a shared HTTP adapter instead of copying ad hoc requests. Trigger with: "build a Procore client", "review Procore SDK patterns", "standardize Procore API calls".

Triggers from the description

build a Procore clientreview Procore SDK patternsstandardize Procore API calls

Arguments

/procore-sdk-patterns [language-and-endpoint-set]
Original author description

Design a thin Procore REST client that preserves endpoint-specific versions, company routing, pagination links, errors, and rate headers. Use when building or reviewing a shared HTTP adapter instead of copying ad hoc requests. Trigger with: "build a Procore client", "review Procore SDK patterns", "standardize Procore API calls".

How it works

  1. Overview
  2. Prerequisites
  3. Instructions
  4. Authentication
  5. Tool Discipline
  6. Output
  7. Examples
  8. Error Handling
  9. Resources
Original SKILL.md headings · 71 lines, 450 words
SKILL.md preview
---
name: procore-sdk-patterns
description: >-
  Design a thin Procore REST client that preserves endpoint-specific versions, company routing, pagination links, errors, and rate headers. Use when building or reviewing a shared HTTP adapter instead of copying ad hoc requests. Trigger with: "build a Procore client", "review Procore SDK patterns", "standardize Procore API calls".
allowed-tools: Read, Grep, Write, Edit
version: 2.0.0
argument-hint: '[language-and-endpoint-set]'
model: inherit
effort: high
license: MIT
author: Jeremy Longshore <jeremy@intentsolutions.io>
tags:
  - saas
  - procore
  - rest-client
  - reliability
compatibility: 'Requires an HTTP client with access to documented Procore REST endpoints and a caller-supplied OAuth token provider.'
---

# Procore Contract-Preserving REST Client

## Overview

Keep the client transport-focused and endpoint versions explicit. Procore resources use multiple REST versions, endpoint-specific page limits, company routing requirements, and actionable response headers that a generic JSON wrapper must not erase.

## Prerequisites

- Enumerated public endpoints and their current reference versions
- Token-provider interface that never exposes client secrets to callers
- Typed error, pagination, rate-budget, and redaction contracts

## Instructions

### Step 1: Model requests explicitly

Represent HTTP method, full documented route, API version, company ID, project ID, query parameters, and body separately. Reject private or guessed routes.

### Step 2: Centralize safe headers

Add the Bearer token at dispatch time. Carry `Procore-Company-Id` from explicit request context where required, and never infer company routing from a cached payload.

### Step 3: Preserve response metadata

Return status, parsed body, request correlation data, `Link`, `Total`, `Per-Page`, `X-Rate-Limit-*`, and `Retry-After` to higher layers.

### Step 4: Bound retries

Retry only safe reads or mutations with a proven idempotency design. Honor reset or retry headers, add jitter, cap attempts, and surface the final provider response.

### Step 5: Test endpoint adapters

Give each resource adapter contract fixtures for success, pagination, permission denial, validation errors, throttling, and server failure. Keep business workflows outside the transport.

## Authentication

The client receives OAuth 2.0 Bearer tokens from an external token provider and injects them only at request dispatch. It must not accept client secrets as ordinary endpoint parameters or log authorization headers.

## Tool Discipline

Use Read and Grep to inspect existing transports, endpoint references, and call sites. Use Write or Edit only for the approved client, adapter, tests, or receipt; do not silently rewrite business workflows or provider data.

## Output

- Typed transport and endpoint adapter boundary
- Pagination, throttling, error, and redaction tests
- Endpoint-version inventory and upgrade ownership

Return which response contracts are preserved and which endpoints remain outside the client.

## Examples

A submittals adapter selects the documented submittals version explicitly and returns Link-header pagination to the caller. The shared transport adds routing and auth headers, but it does not pretend all resources share that version or page size.

## Error Handling

| Failure | Response |
| --- | --- |
| Undocumented route requested | Reject locally and require a public API reference. |
| Company context missing | Fail before dispatch when the endpoint requires company routing. |
| 429 or 503 response | Honor provider timing headers, enqueue work, and retry only within the bounded policy. |
| Ambiguous mutation outcome | Stop automatic retry and reconcile the resource before another write. |

## Resources

- [First-party source notes](references/official-docs.md)
- [REST API overview](https://developers.procore.com/documentation/rest-api-overview)
- [Pagination](https://developers.procore.com/documentation/pagination)
- [Rate limiting](https://developers.procore.com/documentation/rate-limiting)
Files in this package (2)
  • SKILL.md 4 KB
  • references/official-docs.md 1 KB

Versions

The database has no other skills named procore-sdk-patterns.

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version 25465a1ea044 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100procore-common-errors
    Triage Procore OAuth, routing, permission, validation, pagination, throttling, and webhook failures without widening access or retrying blindly. Use when a Procore integration returns 4xx or 5xx responses, empty data, or missing deliveries. Trigger with: "debug Procore 403",…
  • 100procore-local-dev-loop
    Build a deterministic Procore integration loop with fixtures, a Developer Sandbox, and explicit mutation cleanup. Use when developing endpoint adapters, reproducing provider failures, or testing pagination and retry logic locally. Trigger with: "set up Procore local…
  • 100procore-webhooks
    Receive and authenticate Procore construction webhooks. Use when setting up a Procore company or project webhook (hook) endpoint, checking the Authorization Header credential, debugging 401s, or handling resource create, update and delete events such as RFIs or submittals.
  • 100api-design-rest
    Rules for designing and implementing HTTP/REST APIs. Use when creating or reviewing endpoints, request/response shapes, status codes, error formats, pagination, filtering, versioning, idempotency, rate limiting, or API documentation.
  • 100api-design
    Design or review an HTTP/REST/GraphQL API for versioning, pagination, error shapes, idempotency, auth, and evolvability. Use when asked to "design an API", "shape the endpoints", "design the schema", "add a new endpoint", "review this API", or when building/modifying a public or…
  • 100api-design
    Design or review HTTP/REST APIs: resources, OpenAPI, errors, pagination, versioning, idempotency, auth. Use when defining endpoints or contracts, or reviewing an API for consistency and evolvability.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.