Using LLMs for custom integrations¶

Large language models (LLMs) like ChatGPT, Claude, or Gemini can help your team build Public API integrations faster. Use them as assistants for planning, drafting requests, and generating automation steps, then validate all outputs before going live.

What this guide covers¶

How to use LLMs safely with the bsport Public API.
Which data can and cannot be shared in prompts.
Example prompts for Make and n8n, with expected outputs.
Which source to trust first when using LLM-generated output.

Security rules to follow¶

Never share secrets or sensitive data in prompts

Do not paste production API keys, member personal data, payment data, or internal identifiers into ChatGPT, Claude, Gemini, or any other external AI tool.

Before using an LLM: - Use placeholder values like YOUR_API_KEY instead of real credentials. - Remove or anonymize personal or sensitive information and payment-related fields. - Share only the minimum context needed to get useful help. - Review your company AI policy and compliance requirements.

Prompt workflow and source of truth¶

Use the OpenAPI file as the only source of truth for all integration prompts to keep outputs consistent. Require the model to explicitly list missing information instead of guessing fields or values.

Use this workflow: 1. Download the OpenAPI file for the REST version you use from the API reference, or download openapi-v2.yml for V2 and openapi.yml for V1 directly. 2. Attach the file to your LLM conversation. 3. Use the baseline prompt below and adapt it to your endpoint and goal.

Baseline prompt template (copy/paste)¶

You are an integration engineer helping me build a bsport Public API integration.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Return:
1) Step-by-step setup (Make and/or n8n if relevant)
2) Example HTTP request (URL, headers, query params, body)
3) Basic error handling (at least 401, 403, 429, 500 when applicable)
4) Test checklist

Example: Build a ping in Make¶

Prompt (copy/paste):

You are an integration engineer helping me build a bsport Public API integration with Make.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Task:
- Tool: Make (scenario)
- Endpoint: GET /api/v1/monitoring/health/ping/

Requirements:
- Include required headers from the spec (use placeholders for values).
- Add a simple success branch (200) and failure branch (401/403).
- Suggest basic handling for 429/500 if relevant for the gateway/runtime.

Return:
1) Exact module-by-module steps
2) Example request configuration (method, URL, headers)
3) Quick test checklist

Typical result you should expect:

A scenario with an HTTP module configured as GET.
Headers listed with placeholders:
- X-Api-Key: YOUR_API_KEY
- X-Client-ID: YOUR_CLIENT_ID
- X-Company-ID: YOUR_COMPANY_ID
Optional headers only when relevant:
- X-Franchisor-ID: YOUR_FRANCHISOR_ID
- X-Timezone-Name: Europe/Paris
A success path for 200.
A failure path for 401/403 from the spec, and optional handling for 429/500 when returned by gateway or runtime layers.

Example: Build a ping in n8n¶

Prompt (copy/paste):

You are an integration engineer helping me build a bsport Public API integration for n8n.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Task:
- Tool: n8n (workflow)
- Endpoint: GET /api/v1/monitoring/health/ping/

Return:
1) Exact node-by-node steps
2) "HTTP Request" node config (method, URL, headers)
3) "IF" node routing (200 vs 401/403) and a retry suggestion for transient errors (429/500)
4) Quick test checklist

Typical result you should expect: - An HTTP Request node with method GET and the ping URL. - Header definitions using placeholders. - An IF node routing success vs failure. - A short note recommending retry logic for 429 and 500.

LLM prompt cookbook¶

Use these ready-to-copy prompts for common integration tasks. Each prompt keeps the same rule: OpenAPI spec first, placeholders only.

Before you paste a cookbook prompt, decide which tool you want the model to target: - Make: for step-by-step scenarios (modules, routers, error branches). - n8n: for node-by-node workflows (HTTP Request, IF, retries). - Custom code: for runnable code examples (Python, Node.js, etc).

Then, always include a tool line in the prompt using a placeholder (example: Tool: [YOUR_TOOL]). This helps the model pick the right output shape and vocabulary.

1. Create a member¶

You are an integration engineer helping me build a bsport Public API integration.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Task:
- Tool: [YOUR_TOOL] (Make, n8n, or custom code)
- Endpoint: POST /api/v1/management/clients/

Return:
1) Required fields checklist
2) Example HTTP request with placeholders
3) Tool-specific implementation for [YOUR_TOOL] (Make modules, n8n nodes, or runnable code)
4) Validation checklist before production

Expected output: - A field checklist based on the member creation schema. - A request example with placeholder headers and payload values. - Notes about required vs optional fields. - A tool-specific setup or runnable code matching Tool: [YOUR_TOOL]. - A short validation checklist for test environment first.

2. List bookings with filters¶

You are an integration engineer helping me build a bsport Public API integration.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Task:
- Tool: [YOUR_TOOL] (Make, n8n, or custom code)
- Goal: list bookings with date and status filters
- E endpoint: GET /api/v1/management/bookings/ (with a client_id filter)

Return:
1) Query parameters to use
2) Example request URL and headers
3) How to handle pagination safely
4) Tool-specific implementation for [YOUR_TOOL] (including pagination)

Expected output: - A clear list of supported filter parameters from the schema. - A sample paginated request with placeholder headers. - Practical pagination logic (loop until no next page). - A tool-specific setup or runnable code matching Tool: [YOUR_TOOL].

3. Handle `401` and `403`¶

You are an integration engineer helping me build a bsport Public API integration.

Source of truth:
- Use ONLY the attached OpenAPI file.
- Do not rely on memory, guesses, or external sources.

Safety:
- Use placeholders only (no real API key, no personal data, no payment data).

Missing info rule:
- If anything is missing or ambiguous, do not guess. Instead return:
  1) what is missing
  2) where it is needed
  3) what I should provide next

Task:
- Tool: [YOUR_TOOL] (Make, n8n, or custom code)
- Design error handling for auth errors (401 and 403)
- Example endpoint: GET /api/v1/monitoring/health/ping

Return:
1) Decision tree for 401 vs 403
2) Operator actions for each error
3) Tool-specific implementation for [YOUR_TOOL]
4) Alert message templates without sensitive data

Expected output: - A simple decision flow that separates auth issues from permission issues. - Concrete operator actions (check key, check tenant headers, check access scope). - A tool-specific routing example matching Tool: [YOUR_TOOL]. - Safe alert templates that do not expose secrets or member data.

Human validation checklist¶

Before moving to production: - Replace placeholders only inside your secure environment. - Confirm all required headers are present. - Test first in a non-production (staging) environment if available. - Validate failure behavior for 401, 403, 429, and 500. - Treat 429 and 500 as operational safeguards even if they are not declared on every endpoint response in the OpenAPI file. - Keep logs and monitoring enabled for the new workflow.

Common mistakes¶

Asking the LLM to "use my real key from this message".
Pasting real member records into a prompt for troubleshooting.
Deploying generated workflows without manual review.
Treating generated output as guaranteed correct.

Next step¶

After your ping works, ask the LLM to help with one endpoint at a time, then review each generated step against your internal security and QA process.