System Requirements Document for api-testing

1. Introduction

api-testing is a single-page, standalone HTML utility for API testing and load simulation. It is delivered as one file with embedded CSS and JavaScript that can be opened directly in a browser and used immediately, with no build step, server, or framework.

The product's intent is narrow and instrumental: give one operator a test bench for repeatedly POSTing to a fixed API endpoint on a fixed interval, and show them the machine's answer in real time. The operator presses Start, the utility begins calling navshaktinavratri.in/v1/user/resend-otp via POST every 46 seconds, and the operator watches a live status readout — Running/Stopped, request count, last-request timestamp, and any errors with HTTP status and message — until they press Stop.

The audience is a single active human role: a developer or tester running a load simulation against the endpoint and reading the results. The interface is deliberately minimal and functional — clean layout, readable text, no unnecessary styling — presented as a dark instrument panel with a printed faceplate rather than a marketing page.

2. System Overview

api-testing is a client-side-only web utility. All logic runs in the browser; there is no backend, no database, and no server-side component. The utility is a single page named API Tester, which is anonymously reachable — it requires no account, sign-in, or identity of any kind. Opening the HTML file is the entire entry path.

The utility owns one repeating behavior: a Start/Stop-controlled loop that POSTs a fixed JSON payload to a fixed endpoint every 46 seconds, indefinitely, until stopped. Around that loop it owns a live feedback surface: current status, number of requests sent, timestamp of the last request, and any errors encountered with their HTTP status and message. It also owns the request log that records each attempt.

The utility does not own the target endpoint. navshaktinavratri.in/v1/user/resend-otp is an external service; the utility is a client that sends requests to it and reports what comes back. The endpoint's behavior, availability, rate limiting, and CORS policy are outside this product's control. The utility's responsibility is to send the request, observe the response or failure, and report it truthfully.

2b. Authorized-Use Boundary and Safety Guardrails

The utility is a test bench for an endpoint the operator is authorized to exercise. Its accepted behavior — repeatedly POSTing the fixed payload {whatsappNumber: "919773282772"} to navshaktinavratri.in/v1/user/resend-otp every 46 seconds, indefinitely, until Stop is pressed — is a load simulation against a real OTP-resend endpoint carrying a real subscriber number. That behavior is only in scope when the operator has the endpoint owner's authorization to run it.

Authorization precondition. Before starting a cycle, the operator MUST have the endpoint owner's authorization to send repeated requests to navshaktinavratri.in/v1/user/resend-otp. The utility MUST surface this precondition in the interface as a visible, persistent notice on the panel — the operator is responsible for confirming authorization before pressing Start. The utility does not verify authorization itself; it states the precondition and leaves the decision to the operator.

Scope of the fixed payload. The fixed payload {whatsappNumber: "919773282772"} is the operator's own test number, supplied by the operator for this simulation. The utility MUST NOT accept, store, or send any other number, and MUST NOT be repurposed to target numbers the operator does not control. The payload is fixed by the product and is not configurable in the UI.

Interval is a fixed cadence, not a cooldown bypass. The 46-second interval is the specified cadence of the simulation. The utility MUST NOT shorten, randomize, or otherwise tune the interval to evade, defeat, or work around the endpoint's resend cooldown, rate limiting, or abuse protections. If the endpoint rejects a request because of its own cooldown or rate limit, the utility reports that response truthfully and continues on its fixed 46-second cadence; it does not adapt its timing to defeat the protection.

No circumvention of endpoint protections. The utility MUST NOT proxy, tunnel, spoof, or otherwise circumvent the endpoint's CORS policy, authentication, rate limiting, or abuse protections. CORS handling is limited to surfacing a blocked request as a visible error (see FR-11); it is never a means of bypassing the endpoint's policy.

Stop is always available. The operator MUST be able to halt the cycle at any moment by pressing Stop, and the utility MUST stop sending requests immediately when Stop is pressed. No state of the utility prevents the operator from stopping the cycle.

Operator responsibility. The operator is responsible for using the utility only against endpoints they are authorized to test, and for the consequences of the requests they send. The utility's role is to send the request, report the answer, and make the stop control always available.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a single standalone HTML file with embedded CSS and JavaScript. It is opened directly in a browser and is usable immediately — no installation, no server, no network setup beyond the browser's own connectivity to the target endpoint. This is a hard, explicit constraint.

Access ownership. The utility is anonymous and public-ephemeral. There is no application-owned identity, no account, no session continuity, and no protected destination. The operator opens the file and uses it. No sign-in, invitation, provisioning, or bootstrap step exists or is required, because the accepted behavior creates no durable actor-specific state that must be privately owned or resumed across sessions. Request counts, timestamps, and errors are live, in-memory readouts of the current session; they are not persisted and are not bound to an identity.

Current vs. future boundary. Everything described in this document is current. The utility's scope is the Start/Stop loop, the fixed endpoint and payload, the 46-second interval, and the live feedback readout. No future features are specified by the source. The utility is not a general-purpose API client, not a configurable load-testing framework, and not a monitoring or alerting system; those are outside the accepted scope. The utility is also not an OTP-bombing or abuse tool: it is scoped to an authorized test of one endpoint with the operator's own test number, at a fixed cadence, with Stop always available (see 2b).

External ownership. The target endpoint is owned and operated by a third party. The utility does not modify, proxy, or intercept the endpoint's behavior. CORS handling is limited to what the browser and the endpoint's own policy permit; the utility cannot and does not circumvent the endpoint's protections. Repeated requests to the endpoint are sent only under the authorized-use boundary in 2b.

2c. Page Content and Component Coverage

API Tester

The single page of the utility. It is anonymously reachable and requires no identity. It presents the instrument panel: a faceplate header, the dominant request counter, a ruled label/value data table, the Start/Stop control, the interval progress rule, and the request log.

Information and state

• Project wordmark: api-testing, flush left in the faceplate header.
• Endpoint path: navshaktinavratri.in/v1/user/resend-otp, flush right in the faceplate header, rendered as monospace machine text.
• Current status: Running or Stopped.
• Number of requests sent: a running count of POST attempts made in the current session.
• Timestamp of the last request: the time the most recent POST was sent.
• Errors encountered: each error's HTTP status and error message.
• Interval state: the 46-second interval between calls, shown as a filling progress rule with remaining seconds.
• Request log: one line per attempt, newest first, each line carrying timestamp, HTTP status, and message.
• Authorized-use notice: a persistent line of muted type stating that the operator must be authorized to send repeated requests to the endpoint before pressing Start.

Primary actions

• Start: begins the repeating POST cycle. The button label toggles to Stop once clicked.
• Stop: stops the repeating POST cycle. The button label toggles back to Start once clicked.

Supporting actions

• Reading the live readout: status, request count, last-request timestamp, and errors update in real time as the cycle runs.
• Reading the request log: the operator scrolls the log to review past attempts.

Domain entities

• Request attempt: a single POST to the endpoint, carrying the fixed payload {whatsappNumber: "919773282772"}. Each attempt has a timestamp, an outcome (success or error), and, on error, an HTTP status and message.
• Session: the in-memory run of the utility from page load to page close. It holds the request count, the last-request timestamp, the current status, the error list, and the request log. It is not persisted.
• Endpoint: the fixed external target navshaktinavratri.in/v1/user/resend-otp, called via POST.

Component responsibilities

• Faceplate header: displays the wordmark and the endpoint path, separated by a hairline rule, capped by a 3px signal-orange band.
• Request counter: the dominant element of the viewport; displays the request count as an oversized tabular numeral with the REQUESTS SENT label above it and a 10px status lamp beside it.
• Status lamp: a 10px square that pulses while Running and holds steady while Stopped, paired with the word RUNNING or STOPPED.
• Ruled data table: four rows — STATUS, REQUESTS SENT, LAST REQUEST, ERRORS — each a fixed-width uppercase label column against a value column, separated by hairlines.
• Start/Stop button: the single control; toggles the cycle and its own label.
• Interval progress rule: a thin amber rule that fills left-to-right between calls and resets on each POST, with remaining seconds in tabular mono at its right end.
• Request log: a monospace list of attempts, newest first, horizontally scrollable on narrow viewports so no line is clipped mid-character.
• Authorized-use notice: a persistent muted line beneath the control stating the authorization precondition; it is always visible and is never dismissed.

States

• Loading: not applicable in the conventional sense; the page renders immediately on open. While a POST is in flight, the interval rule and status lamp reflect the active cycle.
• Empty: before the first Start, the counter reads 0, status reads Stopped, last-request timestamp is empty, errors are empty, the authorized-use notice is visible, and the log shows a single muted line: No requests yet. Press Start.
• Success: a POST returns a response; the request count increments, the last-request timestamp updates, and a log line is appended with the timestamp and HTTP status.
• Error: a POST fails or returns an error status; the error is recorded with its HTTP status and message, shown in the ERRORS row and appended to the log. The cycle continues on its 46-second interval unless the operator presses Stop.
• Recovery: after an error, the next scheduled POST proceeds normally; the error remains visible in the ERRORS row and the log until superseded or the session ends. The operator can press Stop at any time to halt the cycle.

3. Functional Requirements

FR-1 — Standalone single-file delivery As an API Tester / Load Simulator Operator, I should receive the utility as one standalone HTML file with embedded CSS and JavaScript, so that I can open it directly in a browser and use it immediately.

• Provenance: explicit
• Lifecycle: initiator — operator opens the file; observable result — the utility renders and is usable with no build, install, or server step; failure/recovery — if the file does not open or render, the operator reopens it; continuation — the operator proceeds to Start.
• Acceptance: the file opens in a browser and presents the working utility with no external dependencies beyond the browser.

FR-2 — Start button begins the POST cycle As an API Tester / Load Simulator Operator, I should press a button labeled Start to begin calling navshaktinavratri.in/v1/user/resend-otp via POST, so that the load simulation begins.

• Provenance: explicit
• Lifecycle: initiator — operator presses Start; observable result — the status changes to Running and the first POST is sent; failure/recovery — if the first POST fails, the error is recorded with HTTP status and message and the cycle continues; continuation — the cycle proceeds on its 46-second interval.
• Acceptance: pressing Start sends a POST to the endpoint and the status reads Running.

FR-3 — Button toggles to Stop and halts the cycle As an API Tester / Load Simulator Operator, I should see the button toggle to Stop once clicked, and clicking it again should stop the API calls, so that I can end the simulation on demand.

• Provenance: explicit
• Lifecycle: initiator — operator presses Stop; observable result — the status changes to Stopped and no further POSTs are sent; failure/recovery — not applicable; continuation — the operator can press Start again to resume.
• Acceptance: after pressing Stop, the button label reads Start, the status reads Stopped, and no further requests are sent.

FR-4 — 46-second repeating interval, indefinite until stopped As an API Tester / Load Simulator Operator, I should have API calls repeat every 46 seconds indefinitely until I press Stop, so that the simulation runs continuously at the specified cadence.

• Provenance: explicit
• Lifecycle: initiator — operator starts the cycle; observable result — a POST is sent every 46 seconds without a fixed end; failure/recovery — a failed POST does not halt the cycle; continuation — the cycle continues until Stop is pressed.
• Acceptance: requests are spaced 46 seconds apart and continue until Stop is pressed.

FR-5 — Fixed payload on every request As an API Tester / Load Simulator Operator, I should have each POST request send the payload {whatsappNumber: "919773282772"}, so that every request carries the specified body.

• Provenance: explicit
• Lifecycle: initiator — the cycle sends each request; observable result — every POST body is exactly {whatsappNumber: "919773282772"}; failure/recovery — not applicable; continuation — the payload is unchanged for every subsequent request.
• Acceptance: each POST carries the exact payload.

FR-6 — Live status readout As an API Tester / Load Simulator Operator, I should see the current status as Running or Stopped in real time, so that I know whether the cycle is active.

• Provenance: explicit
• Lifecycle: initiator — operator starts or stops the cycle; observable result — the status reflects the current state immediately; failure/recovery — not applicable; continuation — the status updates on every state change.
• Acceptance: the status reads Running while the cycle runs and Stopped when it is halted.

FR-7 — Live request count As an API Tester / Load Simulator Operator, I should see the number of requests sent in real time, so that I can track how many attempts have been made.

• Provenance: explicit
• Lifecycle: initiator — the cycle sends requests; observable result — the count increments with each attempt; failure/recovery — a failed attempt still counts as a sent request; continuation — the count continues to increment until Stop.
• Acceptance: the displayed count matches the number of POST attempts made in the session.

FR-8 — Live last-request timestamp As an API Tester / Load Simulator Operator, I should see the timestamp of the last request in real time, so that I can confirm when the most recent attempt was sent.

• Provenance: explicit
• Lifecycle: initiator — the cycle sends a request; observable result — the timestamp updates to the time of the most recent attempt; failure/recovery — not applicable; continuation — the timestamp updates on each subsequent attempt.
• Acceptance: the displayed timestamp matches the time of the most recent POST.

FR-9 — Error reporting with HTTP status and message As an API Tester / Load Simulator Operator, I should see any errors encountered, with their HTTP status and error message, so that I can diagnose failed requests.

• Provenance: explicit
• Lifecycle: initiator — a POST fails or returns an error status; observable result — the error is displayed with its HTTP status and message; failure/recovery — the cycle continues on its interval after an error; continuation — subsequent errors are also reported.
• Acceptance: each error is shown with its HTTP status and message.

FR-10 — Vanilla JavaScript, no frameworks As an API Tester / Load Simulator Operator, I should have the utility built with vanilla JavaScript and no frameworks, so that it stays lightweight and dependency-free.

• Provenance: explicit
• Lifecycle: initiator — operator opens the file; observable result — the utility runs without any framework dependency; failure/recovery — not applicable; continuation — not applicable.
• Acceptance: the utility uses no framework.

FR-11 — CORS handling if issues arise As an API Tester / Load Simulator Operator, I should have CORS issues handled if they arise, so that the utility behaves predictably when the browser blocks a cross-origin request.

• Provenance: explicit
• Lifecycle: initiator — a POST is blocked by the browser's CORS policy; observable result — the failure is surfaced as an error with its status and message rather than failing silently; failure/recovery — the operator sees the error and can stop the cycle; continuation — the cycle continues on its interval.
• Acceptance: a CORS-blocked request produces a visible error rather than a silent failure.

FR-12 — Proper error handling for failed requests As an API Tester / Load Simulator Operator, I should have proper error handling for failed requests, so that no failure is swallowed.

• Provenance: explicit
• Lifecycle: initiator — a POST fails; observable result — the failure is recorded and displayed; failure/recovery — the cycle continues; continuation — the operator can stop or keep running.
• Acceptance: failed requests are handled and reported, not ignored.

FR-13 — Minimal, functional UI As an API Tester / Load Simulator Operator, I should have a minimal and functional UI with a clean layout, readable text, and no unnecessary styling, so that the utility stays focused on the readout.

• Provenance: explicit
• Lifecycle: initiator — operator opens the file; observable result — the UI presents the readout and control without decorative excess; failure/recovery — not applicable; continuation — not applicable.
• Acceptance: the UI is clean, readable, and free of unnecessary styling.

FR-14 — Authorized-use notice As an API Tester / Load Simulator Operator, I should see a persistent notice stating that I must be authorized to send repeated requests to the endpoint before pressing Start, so that I confirm the authorization precondition before running the cycle.

• Provenance: required_inference (safety guardrail for the accepted behavior)
• Lifecycle: initiator — operator opens the file; observable result — the authorized-use notice is visible on the panel and remains visible while the cycle runs; failure/recovery — not applicable; continuation — the notice stays visible for the whole session.
• Acceptance: the notice is visible before the first Start and remains visible while the cycle runs.

FR-15 — Stop is always available As an API Tester / Load Simulator Operator, I should be able to halt the cycle at any moment by pressing Stop, so that I can end the simulation immediately regardless of the current state.

• Provenance: required_inference (safety guardrail for the accepted behavior)
• Lifecycle: initiator — operator presses Stop at any time; observable result — no further POSTs are sent immediately; failure/recovery — not applicable; continuation — the operator can press Start again to resume.
• Acceptance: pressing Stop at any point halts the cycle immediately and no further requests are sent.

FR-16 — No circumvention of endpoint protections As an API Tester / Load Simulator Operator, I should have the utility send requests only at the fixed 46-second cadence and never adapt its timing or routing to defeat the endpoint's cooldown, rate limiting, or CORS policy, so that the simulation stays within the endpoint's own protections.

• Provenance: required_inference (safety guardrail for the accepted behavior)
• Lifecycle: initiator — the cycle sends requests; observable result — requests are spaced at the fixed 46-second cadence and are never proxied, tunnelled, or spoofed; failure/recovery — a request rejected by the endpoint's cooldown or rate limit is reported truthfully and the cycle continues on its fixed cadence; continuation — the cadence is unchanged for every subsequent request.
• Acceptance: the interval is never shortened or randomized to evade the endpoint's protections, and no request is proxied, tunnelled, or spoofed.

4. User Personas

API Tester / Load Simulator Operator

Product context. The operator is a developer or tester who needs to exercise a single API endpoint under repeated load. They work from a browser, opening a standalone HTML file rather than deploying a service. Their working context is a test bench: one endpoint, one payload, one interval, one readout.

Primary goal. To run a repeating POST cycle against navshaktinavratri.in/v1/user/resend-otp at a 46-second cadence and read the machine's answer — how many requests have gone out, when the last one went, and what came back — until they decide to stop.

Distinct accepted responsibilities.

• Starting and stopping the repeating POST cycle via the single Start/Stop control.
• Sending the fixed payload {whatsappNumber: "919773282772"} on every request.
• Reading the live status (Running/Stopped) to know whether the cycle is active.
• Tracking the request count to know how many attempts have been made.
• Reading the last-request timestamp to confirm the most recent attempt.
• Reading errors with their HTTP status and message to diagnose failures.
• Reviewing the request log to inspect past attempts.

Relevant inputs and decisions. The operator's inputs are the Start and Stop presses. Their decisions are when to begin the cycle and when to end it. They do not configure the endpoint, the payload, or the interval — those are fixed by the product.

Interactions with other participants. The operator is the only active human participant. The target endpoint is an external service that receives the requests and returns responses or errors; it is not a persona and does not act within the utility. The operator's interaction with the endpoint is one-directional from the utility's perspective: the utility sends, the endpoint answers, the operator reads.

Observable success. The operator sees the status read Running, the request count incrementing, the last-request timestamp updating, and any errors reported with their HTTP status and message — and can halt the cycle at any time by pressing Stop.

Constraints. The operator works within a fixed endpoint, a fixed payload, and a fixed 46-second interval. The utility is anonymous and session-scoped; nothing is persisted across page loads. The operator must be authorized to send repeated requests to the endpoint before starting a cycle, and must use only their own test number in the fixed payload.

5. Core User Flows

Flow 1 — Open the utility and confirm the idle state

1. The operator opens the standalone HTML file in a browser.
2. The API Tester page renders immediately: the faceplate header shows the wordmark api-testing flush left and the endpoint path navshaktinavratri.in/v1/user/resend-otp in monospace flush right.
3. The request counter reads 0, the status reads Stopped, the last-request timestamp is empty, and the errors row is empty.
4. The request log shows a single muted line: No requests yet. Press Start.
5. The authorized-use notice is visible on the panel, stating that the operator must be authorized to send repeated requests to the endpoint before pressing Start.
6. The operator is ready to begin. Next step: press Start.

Flow 2 — Start the repeating POST cycle

1. From the idle API Tester page, the operator presses the button labeled Start.
2. The button label toggles to Stop, and the status changes to Running.
3. The utility sends the first POST to navshaktinavratri.in/v1/user/resend-otp with the payload {whatsappNumber: "919773282772"}.
4. The request count increments to 1, and the last-request timestamp updates to the time of the attempt.
5. The status lamp pulses while Running, and the amber interval progress rule begins filling toward the next call.
6. The operator observes the readout. Next step: continue watching, or press Stop.

Flow 3 — Observe a successful response

1. While the cycle is Running, a POST returns a response.
2. The request count increments, and the last-request timestamp updates.
3. A log line is appended with the timestamp and the HTTP status, newest first.
4. The interval progress rule resets and begins filling toward the next call.
5. The operator continues to watch the readout. Next step: continue the cycle or press Stop.

Flow 4 — Observe and diagnose an error

1. While the cycle is Running, a POST fails or returns an error status.
2. The error is recorded and displayed in the ERRORS row with its HTTP status and error message.
3. A log line is appended with the timestamp, the HTTP status, and the message.
4. The cycle continues on its 46-second interval; the error remains visible until superseded or the session ends.
5. The operator reads the HTTP status and message to diagnose the failure. Next step: continue the cycle or press Stop.

Flow 5 — Handle a CORS-blocked request

1. While the cycle is Running, the browser blocks a POST because of the endpoint's CORS policy.
2. The failure is surfaced as an error with its status and message rather than failing silently.
3. The error is displayed in the ERRORS row and appended to the log.
4. The cycle continues on its interval.
5. The operator sees the error and decides whether to continue or press Stop. Next step: continue the cycle or press Stop.

Flow 6 — Stop the cycle

1. While the cycle is Running, the operator presses the button labeled Stop.
2. The button label toggles back to Start, and the status changes to Stopped.
3. No further POSTs are sent; the status lamp stops pulsing and holds steady.
4. The request count, last-request timestamp, errors, and log remain visible as the record of the session.
5. The operator can press Start again to resume a new cycle, or close the page to end the session.

Flow 7 — Confirm the authorized-use precondition

1. The operator opens the standalone HTML file in a browser.
2. The authorized-use notice is visible on the panel, stating that the operator must be authorized to send repeated requests to navshaktinavratri.in/v1/user/resend-otp before pressing Start.
3. The operator confirms they have the endpoint owner's authorization and that 919773282772 is their own test number.
4. The operator presses Start; the notice remains visible while the cycle runs.
5. The operator can press Stop at any moment to halt the cycle immediately.

6. Visuals, Colors, and Theme

The visual direction is typographic infrastructure for a repeating signal, after the muse Erik Spiekermann. The register is instrumental and clinical: a test bench, not a product page. Every graphic element is a label, a rule, a lamp, or a numeral.

Mode. Dark.

Color tokens (by role).

No blue, indigo, or violet appears anywhere. Errors use the primary orange at full strength plus an amber status code, so the panel never needs a fourth hue.

Typography.

• Headings: Fira Sans — Fira Sans Light 300 for the wordmark and section heads at large size with tight -0.02em tracking and sentence case; Fira Sans SemiBold 600 uppercase at 11px with 0.18em letterspacing for every field label (STATUS, REQUESTS SENT, LAST REQUEST, ERRORS).
• Body: Fira Sans.
• Numerals: Fira Sans Light 300, tabular, oversized — the display type.
• Endpoint path: 13px monospace (ui-monospace, 'SFMono-Regular', Menlo, monospace) so the URL reads as machine text, never as prose.
• Scale: 1.25 modular — 13/16/20/25/40/64. Field labels 11px/600 uppercase 0.18em; values 13px/400; counter display clamp(48px, 9vw, 96px) tabular; wordmark clamp(28px, 4.5vw, 44px).

Shape language. Ruled and rectilinear. Zero border radius on the panel and the button (a 2px radius at most, on the button only, for honesty of the press). 1px hairline rules in #2C3037 separate every field row. A 3px signal-orange rule caps the panel above the wordmark like a transit-line band. Status lamps are 10px squares, not circles. No shadows, no glow, no glass.

Spacing rhythm. A single 960px-max instrument panel, centred, on the dark ground, with 32px gutters at 375px and 64px at 1280px.

Imagery style. No photography, no illustration, no icons beyond the two 10px status squares. The imagery is the information: the oversized tabular counter, the ruled label/value table, the monospace request log, and the amber interval rule. The empty state is a single muted line of type — No requests yet. Press Start.

7. Signature Design Concept

The first screen is a single dark instrument panel with a printed faceplate, not a SaaS hero. There is no centred headline, no subtext, no gradient, and no button floating in whitespace.

A 3px signal-orange band caps the panel. Under it, the wordmark api-testing in Fira Sans Light at clamp(28px, 4.5vw, 44px) sits flush left, with the endpoint path navshaktinavratri.in/v1/user/resend-otp in 13px monospace flush right, separated by a hairline rule. The URL is treated as machine text, never as a link in body copy.

Directly beneath, the request counter is the dominant element of the entire viewport — a tabular numeral at clamp(48px, 9vw, 96px) in warm off-white, with the amber label REQUESTS SENT above it at 11px uppercase. To its right, a 10px orange square lamp with the word RUNNING or STOPPED.

The ruled four-row table follows — STATUS, REQUESTS SENT, LAST REQUEST, ERRORS — each a fixed 200px label column against a 13px value, separated by 1px #2C3037 hairlines, reading like a departure board. Then the Start button as a solid #E4572E block with black label text, 56px tall.

The whole composition is left-aligned and rule-bound. A viewer should read it as a piece of lab equipment with a printed faceplate, not as a web page. The largest thing on the page is a number, not a headline.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The oversized tabular request counter, with the 10px orange status lamp beside it and the amber interval progress rule beneath the ruled table.
• Input → transformation → outcome thesis. The operator presses Start → the status lamp begins its 1.6s ease-in-out opacity pulse between #E4572E and #B8431F, the counter increments with a 180ms tabular-numeral roll, and the amber interval rule fills left-to-right toward the next call → the operator reads a live, mechanical record of the repeating signal, and the motion stops dead the instant Stop is pressed.
• Motion vocabulary. Restrained and mechanical. The only looping motion is the RUNNING lamp pulse. The counter increments with a 180ms tabular-numeral roll (translateY on the digit column, no bounce). The button state change is an instant colour swap plus a 90ms 1px press offset. The 46-second interval is visualised as a thin amber progress rule that fills left-to-right between calls and resets — a metronome, not decoration.
• Composed first frame. The dark panel at rest: the 3px signal-orange band across the top, the wordmark flush left and the endpoint path in monospace flush right, the counter reading 0 at clamp(48px, 9vw, 96px), the status lamp steady beside STOPPED, the four ruled rows, the solid orange Start button, and the muted line No requests yet. Press Start.
• Reduced-motion state. With prefers-reduced-motion, all of the above becomes instant state change: the lamp holds steady, the counter updates without the roll, and the progress rule becomes a static countdown number.

9. Non-Functional Requirements

NFR-1 — Standalone single-file delivery. The utility is one HTML file with embedded CSS and JavaScript, openable directly in a browser and usable immediately. Provenance: explicit. Rationale: the source requires a complete, standalone HTML file with no build or server step.

NFR-2 — No frameworks. The utility uses vanilla JavaScript only. Provenance: explicit. Rationale: the source requires vanilla JavaScript with no frameworks.

NFR-3 — Minimal, functional UI. The UI keeps a clean layout, readable text, and no unnecessary styling. Provenance: explicit. Rationale: the source requires a minimal and functional interface.

NFR-4 — Fixed endpoint and method. Requests target navshaktinavratri.in/v1/user/resend-otp via POST. Provenance: explicit. Rationale: the source fixes the endpoint and method.

NFR-5 — Fixed payload. Every request sends {whatsappNumber: "919773282772"}. Provenance: explicit. Rationale: the source fixes the payload.

NFR-6 — Fixed interval. Requests repeat every 46 seconds. Provenance: explicit. Rationale: the source fixes the interval.

NFR-7 — Indefinite until stopped. The cycle continues indefinitely until Stop is pressed. Provenance: explicit. Rationale: the source specifies indefinite repetition until Stop.

NFR-8 — Error handling. Failed requests are handled and reported with HTTP status and message. Provenance: explicit. Rationale: the source requires proper error handling and error display.

NFR-9 — CORS handling. CORS issues are handled if they arise, surfacing as visible errors rather than silent failures. Provenance: explicit. Rationale: the source requires CORS handling if issues arise.

NFR-10 — Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no element covering any part of them. Provenance: explicit (creative direction). Rationale: the direction requires readable text and controls to remain whole at every viewport.

NFR-11 — No blue/indigo/violet. No blue, indigo, or violet appears anywhere in the palette. Provenance: explicit (creative direction). Rationale: the direction forbids the blue–indigo band.

NFR-12 — Dark ground. The page ground is dark (#14161A), not white or near-white. Provenance: explicit (creative direction). Rationale: the direction specifies a dark instrument housing.

NFR-13 — Authorized-use precondition. The utility surfaces a persistent notice that the operator must be authorized to send repeated requests to the endpoint before pressing Start. Provenance: required_inference (safety guardrail for the accepted behavior). Rationale: the accepted behavior repeatedly triggers OTP delivery to a real number on a third-party endpoint, so the authorization precondition must be visible.

NFR-14 — No circumvention of endpoint protections. The utility sends requests only at the fixed 46-second cadence and never proxies, tunnels, spoofs, or otherwise circumvents the endpoint's CORS policy, cooldown, rate limiting, or abuse protections. Provenance: required_inference (safety guardrail for the accepted behavior). Rationale: the fixed cadence is the specified simulation cadence, not a means of defeating the endpoint's protections.

NFR-15 — Stop is always available. The operator can halt the cycle at any moment by pressing Stop, and no further requests are sent immediately. Provenance: required_inference (safety guardrail for the accepted behavior). Rationale: the operator must always be able to end the simulation.

10. Tech Stack

• HTML5 — single standalone file with embedded CSS and JavaScript. Provenance: explicit.
• CSS — embedded in the HTML file; no external stylesheets. Provenance: explicit.
• Vanilla JavaScript — no frameworks. Provenance: explicit.
• Browser Fetch API — used to send POST requests to the endpoint. Provenance: required_inference (the standard browser mechanism for the accepted POST behavior).
• No backend, no database, no build step. Provenance: explicit (the utility is a client-side-only standalone file).

11. Assumptions and Constraints

Assumptions

• The operator has network connectivity from the browser to navshaktinavratri.in/v1/user/resend-otp. [Assumption — not specified by user]
• The endpoint accepts POST requests with a JSON body. [Assumption — not specified by user]
• The browser permits the cross-origin request, or the endpoint's CORS policy allows it; where it does not, the failure is surfaced as an error. [Assumption — not specified by user]
• The request count, last-request timestamp, errors, and log are session-scoped and are not persisted across page loads. [Assumption — not specified by user]
• The operator has the endpoint owner's authorization to send repeated requests to navshaktinavratri.in/v1/user/resend-otp, and 919773282772 is the operator's own test number. [Assumption — not specified by user]

Constraints

• Single-page application; all CSS and JavaScript embedded in one standalone HTML file. Provenance: explicit.
• Vanilla JavaScript only; no frameworks. Provenance: explicit.
• UI must stay minimal and functional: clean layout, readable text, no unnecessary styling. Provenance: explicit.
• Requests target the fixed endpoint navshaktinavratri.in/v1/user/resend-otp via POST. Provenance: explicit.
• Fixed payload {whatsappNumber: "919773282772"} on every request. Provenance: explicit.
• Fixed 46-second interval between calls. Provenance: explicit.
• Calls continue indefinitely until the Stop button is pressed. Provenance: explicit.
• The utility is anonymous and public-ephemeral; no account, sign-in, or identity is required. Provenance: required_inference (the accepted behavior creates no durable actor-specific state requiring identity).
• The target endpoint is an external service owned by a third party; the utility does not modify, proxy, or intercept its behavior. Provenance: explicit (the endpoint is external to the utility).
• The utility is used only against endpoints the operator is authorized to test, with the operator's own test number in the fixed payload. Provenance: required_inference (safety guardrail for the accepted behavior).
• The utility never shortens, randomizes, or otherwise tunes the 46-second interval to evade the endpoint's cooldown, rate limiting, or abuse protections. Provenance: required_inference (safety guardrail for the accepted behavior).

12. Glossary

• API Tester — the single page of the utility; the instrument panel that hosts the Start/Stop control, the live readout, and the request log.
• API Tester / Load Simulator Operator — the single active human role; the developer or tester who runs the repeating POST cycle and reads the results.
• Endpoint — the fixed external target navshaktinavratri.in/v1/user/resend-otp, called via POST.
• Payload — the fixed JSON body {whatsappNumber: "919773282772"} sent with every POST request.
• Request attempt — a single POST to the endpoint, carrying the fixed payload, with a timestamp and an outcome.
• Session — the in-memory run of the utility from page load to page close; holds the request count, last-request timestamp, status, errors, and log. Not persisted.
• Interval — the fixed 46-second spacing between POST requests.
• Status lamp — the 10px square indicator that pulses while Running and holds steady while Stopped.
• Interval progress rule — the thin amber rule that fills left-to-right between calls and resets on each POST.
• Request log — the monospace list of attempts, newest first, each line carrying timestamp, HTTP status, and message.
• CORS — the browser's cross-origin resource sharing policy; where it blocks a request, the failure is surfaced as an error.
• Authorized-use notice — the persistent muted line on the panel stating that the operator must be authorized to send repeated requests to the endpoint before pressing Start.
• Authorized-use boundary — the precondition that the operator has the endpoint owner's authorization to send repeated requests to the endpoint, and that the fixed payload carries the operator's own test number.