API, Webhook, JSON and Endpoint Explained

The shortest explanation

An API is the rules for talking to a service. An endpoint is a specific API address. A request is a message sent to that address. A webhook is an incoming request triggered by an event. JSON is a common format for the data inside the request.

Think of an API as a menu

A restaurant menu tells you what can be ordered and how to ask for it. An API does the same for software. Documentation might define an endpoint for prices, another for positions and another for placing orders. Each endpoint defines which HTTP method to use, what authentication is needed, what fields are accepted and what response comes back.

GET  /api/positions      -> ask for current positions
POST /api/order          -> send a new order request
DELETE /api/order/123    -> request cancellation

HTTP methods are verbs

GET usually retrieves data. POST usually sends or creates something. PUT/PATCH often update. DELETE usually removes or cancels. These are conventions, not guarantees; the API documentation is authoritative.

An endpoint is an address with a job

If a Worker lives at https://example.com/api/webhook, that URL can be an endpoint. The path /api/webhook distinguishes it from /api/health or /api/tips. A good service gives each endpoint a narrow responsibility.

A webhook is event-driven

Polling means your program repeatedly asks for changes. A webhook means the source calls you when something happens. This can reduce delay and unnecessary requests, but it means your endpoint is publicly reachable and must verify who is allowed to call it.

TradingView
  event occurs
     ↓
POST https://example.com/api/webhook
     ↓
Your receiver validates the message
     ↓
Your internal bot logic runs

JSON labels the data

Without structure, a message such as BTCUSD BUY 0.01 requires custom parsing. JSON makes each value explicit.

{
  "event_id": "evt-001",
  "symbol": "BTCUSD",
  "action": "buy",
  "size": 0.01,
  "dry_run": true
}

Quotes matter. "0.01" is text; 0.01 is a number. true is a boolean; "true" is text. A receiver should validate types instead of assuming they are correct.

What a robust receiver checks

The HTTP method is allowed.
The request is authenticated or signed.
The body is valid JSON if JSON is expected.
Required fields exist and have the correct types.
The event timestamp is not stale.
The event ID has not already been processed.
Unexpected values are rejected before any important action.

Status codes tell the sender what happened

Code	Meaning in plain English	Typical bot example
200 / 201	Accepted/succeeded	Event saved or action completed
400	Bad request	Malformed JSON or missing required field
401 / 403	Not authenticated / not allowed	Wrong secret or forbidden origin
404	Endpoint not found	Wrong URL path
409	Conflict	Duplicate event ID
429	Too many requests	Rate limit reached
500	Server-side error	Unhandled backend failure

Common beginner mistakes

Putting an API key directly in frontend JavaScript where every visitor can read it.
Assuming a 200 response proves a later broker action succeeded.
Retrying a timed-out order without checking whether the first request already succeeded.
Logging passwords or full authorization headers.
Using the same webhook URL as the only authentication mechanism.
Accepting arbitrary JSON and passing it directly into execution code.

Useful mental model: external input is untrusted. Parse it, validate it, normalize it into your own small internal event format, and only then let business logic use it.