American Coaster Enthusiasts
American Coaster Enthusiasts
Membership & Events Platform
Preview environment
Beta
Preview theme
Viewing as
Switch role, one click, no password
Jane CoasterMemberIndividual membership, renews in 42 daysWalt AirtimeMemberFamily of three, auto-renew already onStefanie BrooksContractor staffContractor staff, member services. Records, mailings and events. No financial access.Ben BrooksContractorContractor. Operations and the bookkeeping ACE contracts out (RFP 3.D).ACE TreasurerTreasurerFinancial reporting and statistics. No member records or contact data.ACE PresidentPresidentEverything, and the only role that grants access.Pat Rivera (Mid-Atlantic Rep)Regional RepRegional representative. Sees ONLY their own region: roster, renewals due, and a newsletter list. No other region, no financials, no staff console. Sign out

Website sync & API

ACE's volunteer web team gets membership updates daily by file, or live by API, in whatever format they prefer (RFP 3.B.6). Both are generated from the same database driving every page in this preview, so the website is never stale.

Daily sync file

Written every night and delivered to the web team's pickup location.

Download today's file (CSV)

Live API

Same data, real time. Call it with ?since= an ISO date for the daily delta ACE's website loads, or page the full set with ?offset=. The response carries the true total, not a truncated sample.

GET /api/sync/members.json

Authenticated in production; anonymized sample here.

ACE’s website stays with ACE’s volunteers. RFP 3.H.4 keeps website design, development, maintenance and hosting outside this contract, and we are not proposing to take any of it on. This platform is the online membership system RFP 2.N makes the Contractor responsible for. Its job on this page is to feed ridewithace.com the membership changes the web team needs, daily, by file or API, in whatever format they prefer. The member-only directory and status lookup on ACE’s site keep working exactly as they do now, on fresher data.

How this data is protected (RFP 3.F.3)

Confidentiality here is enforced by the code on every request, not by hiding menus. Three rules hold on each route:

RuleWhat it means in practice
A member sees only themselvesA member's session is bound to their own record by a signed token. Changing the member number in the address, or hand-crafting a cookie, does not open anyone else's record: the signature will not match.
Staff see only their capabilityEach staff role carries an explicit capability list. The financial reports, the member exports and the sync API each require the matching capability; the page is not merely hidden, the data route itself refuses the request.
Every download is authorised and loggedThe CSV and JSON exports and the API require the capability or a bearer token, and each membership change is attributed to the person who made it in the audit log.

These rules are held in place by 60 automated access checks that run before every release: for each role, against every route, the expected outcome (open or blocked) is declared and verified, so a future change cannot quietly widen access without a test failing. Signed renewal links are single-use and expire; secrets are never shipped with a working default.

General office and records (RFP 3.E, 3.F)

RFPRequirementHow it is met
3.E.1Live phone, answered "American Coaster Enthusiasts"Service. Staffed 10:00 to 4:00 Eastern on business days by the principals, with a professional answering service as backup. Committed in our proposal.
3.E.2Voicemail with recorded after-hours messageService. Voicemail transcribed to email and returned the next business day.
3.E.3info@, membership@, registration@ emailService. One-business-day response commitment. Membership and registration mail is answered from the same records shown here, so replies carry the member's actual status.
3.E.4Electronically transfer data to officers and volunteersSoftware. The sync file and API on this page, plus role-scoped exports. Officers receive only what their role permits, and every download is audit-logged.
3.E.5PCI DSS compliance for stored card dataSoftware. Card data is entered directly into the processor's hosted fields and tokenised; it never reaches a system we operate, so there is no stored cardholder data to protect. Level 1 processors only.
3.E.6Encrypted off-site backupsBoth. Encrypted daily off-site backups with point-in-time recovery and quarterly tested restores, plus the monthly snapshot to ACE-controlled storage described below.
3.F.1All records remain ACE propertyContract. Stated in our proposal without qualification. Nothing here is licensed to ACE; it is ACE's.
3.F.2Secure storageSoftware. Role-based access enforced on every route, not just hidden menus, and every record change attributed in the audit log.
3.F.3Confidentiality; reasonable precautionsSoftware. Members reach only their own record; staff roles reach only the data their capability allows; exports and the API require the matching capability or a bearer token.
3.F.4Records delivered on terminationBoth. Complete CSV and JSON export at any time, and the monthly snapshot means ACE already holds a current copy before any termination.

Data ownership, made physical

Beyond the daily sync: a complete monthly snapshot of the membership database and financial records is delivered to storage ACE controls, with documentation a successor could operate from. ACE always holds a current copy of its own data. Exports in standard formats are available at any time and immediately at termination.