Publishing your App

Before your app can be published in the Camping.care App Store, it must pass a certification review. This document describes everything you need to prepare. Read it fully before submitting.

1. App Identity & Basic Information

Make sure the following are configured correctly in your App Store dashboard before submitting:

2. API Permissions (Scopes)

The Camping.care API has over 600 individual scopes. You must only register scopes your app actively uses.

2.1 What you need to document

For every scope registered in your app settings, provide:

• The scope name
• The specific feature in your app that requires it
• The data fields it accesses

An example:

2.2 Scope rules

• No speculative scopes. Do not register a scope because you might use it later. Future scope additions require re-certification.
• Write scopes need justification. Every write scope must map to a specific, user-initiated action.
• Minimise access to personal data. If a scope gives access to guest data, list only the fields your app actually displays or processes.
• Webhooks follow the same rule. Only subscribe to events your app actually handles.

3. Webhooks

Webhooks allow Camping Care to push real-time event notifications to your app, so you don't need to poll the API. When a relevant event occurs in the platform, such as a new reservation being made or a payment being added, Camping.care sends an HTTP POST request to your registered webhook URL with the event data.

3.1 When to use webhooks

Use webhooks when your app needs to react to things happening in Camping Care without the user having the app open. Common use cases:

If your app only needs to display data when the operator has it open, you may not need webhooks at all, a regular API call when the app loads is sufficient.

3.2 How to register webhooks

In your app settings in the App Store dashboard, add the URL(s) your app should receive events on. You can register separate URLs per event type or use a single URL and route events by type in your own code.

3.3 Technical requirements

• Respond with HTTP 200 within 10 seconds. Camping Care will consider the delivery failed if your endpoint does not respond in time.
• Your endpoint must be idempotent. Camping Care may retry delivery on failure, so receiving the same event twice must not cause duplicate actions (e.g. double-sending an email or creating duplicate records).
• Your endpoint must be HTTPS.
• Process events asynchronously. Accept the webhook immediately and do any heavy processing in a background job; do not do slow work inside the request handler.
• Do not rely on event order. Events may occasionally arrive out of sequence; design your logic to handle this.
  
  

3.4 What to document for certification

For each webhook event your app subscribes to, explain:

• Which event(s) you subscribe to
• What your app does when it receives that event
• Whether any personal data in the payload is stored, and if so, for how long

An example:

4. Privacy & Data Handling

Campsite operators are data controllers under the GDPR. When they install your app, you become a data processor. This section documents how you handle that responsibility.

4.1 Privacy Policy

You app must have a publicly accessible privacy policy before submission. It must:

• Include a English version (other languages are optional).
• Accurately describe what data your app collects, stores, and transmits.
• List any third-party services that receive data (e.g. your hosting provider, analytics tools); including their name, country, and purpose.
• State your data retention periods.
• Explain how users can request deletion of their data.
• Be linked in your App Store listing.

4.2 Data Inventory

Before submitting, map out every category of personal data your app touches. "Personal data" includes names, email addresses, phone numbers, IP addresses, booking details, and anything else that could identify an individual.

For each category, be able to answer:

• Is it stored by your app? If so, where and how long?
• Is it transmitted to a third party?
• What is the legal basis under GDPR Art. 6?

4.3 Technical data protection requirements

• HTTPS is required for your App URL.
• Tokens must be stored securely, never in localStorage, plaintext files, or logs.
• Personal data must be encrypted at rest if stored by your app.
• OAuth tokens must never be logged or sent to third parties.
• No scraping, your app may only access data through the Camping Care API/Webhooks, not by scraping the UI.

4.4 Data subject rights

You must have a process for operators (and their guests) to request deletion of their data from your systems. Be ready to describe:

• How they contact you (e.g. email address)
• Your (max) response time
• What gets deleted and how
• Whether a confirmation is sent

5. Technical Requirements

5.1 Authentication

Your app must implement the OAuth 2.0 flow correctly. See the Authentication docs for the full reference.

Key requirements:

• Exchange the authtokens URL parameter for an idToken and refreshToken via POST /v21/oauth/token. Never use the raw authtoken to call the API.
• Refresh the idToken before it expires (every 3600 seconds) using POST /v21/oauth/refresh_token, do not force users to reinstall when the token expires.
• Send the X-Admin-Id header on all adminstration-scoped API requests.
• Handel 401 Unauthorized responses gracefully (auto-refresh or a clear prompt, no white screens).

5.2 Stability & Error handling

• The app must not crash or show unhandled exceptions during normal use.
• API errors (4xx/5xx) must result in a user-friendly message, not a raw error dump.

• If you use webhooks:

  • Respond with HTTP 200 within 10 seconds.
  • Your endpoint must be idempotent, Camping Care may retry on failure.
• Do not poll the API more frequently than once every 60 seconds; use webhooks for real-time events.
• Your app must not make API calls on behalf of administrations it is not installed in.

5.3 Security

• No SQL injection vulnerabilities.
• No Cross-Site Scripting (XSS) vectors, escape all user-supplied output.
• No Cross-Site Request Forgery (CSRF) vulnerabilities.
• No hardcoded secrets in your codebase; use environment variables or a secret manager.
• Run a dependency audit (npm audit, composer audit, etc.) and resolve any critical CVEs before submitting.
• Apps that handle payments must provide a summary of a security audit or penetration test.

6. Live Demo

Every first-time publication and every major update requires a live demo with the Camping.care team. The demo verifies that the app works as described, that scope usage matches the declared purpose, and that the install/uninstall flow is clean.

6.1 Before scheduling the demo

Make sure:

• The app is deployed to its production HTTPS URL.
• The app is installed in a test Camping Care administration (park/campsite).
• All features described in the App Store listing are functional.
• This completed certification checklist has been submitted at least 3 business days before the demo.
  
  

6.2 What the demo covers

• You introduce the app: what it does and who it's for.
• Install flow: OAuth install from the App Store, scope consent screen.
• Core functionality walkthrough; all major features with real API calls.
• Privacy walkthrough: where personal data appears, how it's stored, how deletion works.
• Q&A and outcome.
  
  

6.3 Pass criteria

The demo passes if:

1. The app installs and uninstalls cleanly, leaving no orphaned data.
2. All listed features work without errors.
3. Scope usage during the demo matches the declared purpose in Section 2.
4. Personal data is not exposed unnecessarily.
5. Error scenarios are handled gracefully, no crashes or raw stack traces.
6. You can explain the data flow and storage architecture when asked.
   
   

6.4 Outcomes

The reviewer communicates the outcome within a few business days after the demo.

7. Ongoing Obligations

Certification is not one-time. Published apps must stay compliant.

7.1 Changes that require re-certification

Submit an updated certification document (and usually a new demo) when you:

• Add new OAuth scopes or webhook subscriptions
• Start storing a new category of personal data or change retention periods
• Add a new third-party data processor
• Make significant changes to core functionality (new integrations, payment handling, etc.)
• Transfer the app to a different developer or company

Minor bug fixes and UI changes do not require re-certification, but do notify the Camping Care team!

7.2 Security incidents

If you discover a security incident, data breach, or critical bug, notify Camping.care at support@camping.care within 24 hours. Failure to report may result in immediate suspension.

7.3 Support & Availability

• Respond to operator support requests within 5 business days.
• Notify Camping Care at least 7 days in advance of planned maintenance.
• Keep your app compatible with the current Camping Care API version.

8. Submitting for Review

1. Email support@camping.care with the subject line App Certification - [Your App Name], attaching or linking your completed publishing document and privacy policy.
2. The team will respond to schedule the live demo.
3. After a successful demo, your app will be reviewed internally and published.

Questions? Reach out at support@camping.care or visit the Developer Docs.