specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Florist One
providerId: florist-one
generated: '2026-09-10'
method: probed
source: >-
  live probe of https://www.floristone.com/api/rest/flowershop/getproducts (2026-09-10),
  https://www.floristone.com/api/flowers-api-faq/,
  https://www.floristone.com/api/print_api_legal/
created: '2026-05-04'
modified: '2026-09-10'
supersedes: >-
  REPLACED A SCAFFOLD. The prior version of this file (method: generated, dated 2026-05-04)
  declared X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset / RateLimit-Policy
  headers, a 429 on exhaustion, and five per-tier limits across free, professional and
  enterprise tiers. Florist One publishes none of that and returns none of those headers.
  All of it has been removed.
limit_count: 0
tags:
  - Delivery
  - Ecommerce
  - Florists
  - Flowers
  - Gifts
  - Rate Limiting
description: >-
  Florist One publishes no rate limit for its REST API and emits no rate-limit signal on
  the wire. An agent or client has no way to learn its budget in advance, and no way to
  learn it has been throttled other than by a request failing. This is an honest zero, not
  an unmeasured field.
headers: {}
headers_observed: []
headers_probe:
  fetched: '2026-09-10'
  url: https://www.floristone.com/api/rest/flowershop/getproducts?category=fx&count=2&start=1
  http_status: 403
  response_headers_returned:
    - date
    - content-type
    - allow
    - server
    - x-time-in-parse
    - x-time-in-ontaffyrequest
    - x-time-in-resource
    - x-time-in-serialize
    - x-time-in-taffy
    - x-powered-by
  finding: >-
    No RateLimit-*, X-RateLimit-*, or Retry-After header on the response. The only
    non-standard headers are Taffy framework timing counters, which identify the
    ColdFusion REST stack behind Microsoft-IIS/10.0 but say nothing about quota.
  caveat: >-
    This was an unauthenticated request that returned 403 before reaching application
    logic. An authenticated response could in principle carry headers this probe cannot
    see; nothing in the public documentation suggests it does, and the technical
    documentation that would settle it is behind the API-key login.
responseCodes: {}
responseCodes_note: >-
  No status code for throttling or quota exhaustion is documented. 403 is confirmed as the
  unauthorized response; 429 was never observed and is never mentioned.
limits: []
limits_note: >-
  Zero published limits. The FAQ, the how-it-works page and the API Agreement contain no
  request ceiling, burst allowance, concurrency cap or fair-use clause of any kind. The
  API Agreement's only volume-adjacent language forbids uses that would result in
  "excessive non-acceptance, non-delivery, refunds and/or chargebacks" — a commercial abuse
  clause, not a rate limit.
policies:
  - name: No published backoff guidance
    description: >-
      Florist One documents no retry or backoff expectation, and its own sample code
      performs no retry. A client must choose its own policy blind — and must do so
      carefully, because the write operations have no idempotency key, so a naive retry of
      a placeorder call risks a duplicate real-world flower delivery. See
      conventions/florist-one-conventions.yml.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com