Web Forms

What this web form flow covers

Web forms in the current project are most concretely represented by the public contact form flow. The website sends requests to a backend contact endpoint, the backend validates the payload, protects the route with lightweight rate limits, and sends operational emails when a submission is accepted.

This is a simpler channel than Instagram or LinkedIn, but it matters because it is the cleanest example of direct site capture without depending on a third-party social platform.

Public form submission path

The website contact page already posts real form data to the backend using the public contact API route. The submission payload supports name, email, subject, message, and optional phone and company values, which gives the project a structured direct-intake path for website-originated inquiries.

That means web forms are already part of the real product footprint, even if they are currently lighter than the social-media capture stack.

• Live route: the backend registers a real `/api/contact` route for inbound website submissions.
• Structured payload: the route accepts core contact details plus optional phone and company context.
• Website-to-backend handoff: the front end already calls this route from the public contact page.

Validation and rate limiting

Before the submission is accepted, the backend checks for required fields and validates email format. It also applies a simple in-memory IP-based rate limit so the route cannot be spammed repeatedly in a short time window.

This is an important part of the current implementation because it shows that web forms are treated as an operational intake surface, not only as an unguarded email forwarder.

• Required field checks: name, email, subject, and message must be present.
• Email validation: the route rejects clearly invalid email formats before processing.
• IP-based throttle: the current implementation allows a limited number of submissions per hour from the same source.

Team notification and confirmation emails

Once a submission passes validation, the backend builds a formatted HTML email for the OrcaPulse team and sends it to support. It also sends a confirmation email back to the person who submitted the form so they know their message was received.

This gives the current web-form flow a two-sided communication model: internal visibility for the team and external reassurance for the user.

• Internal notification: accepted submissions generate a structured message to `support@orcapulse.ai`.
• Sender confirmation: the submitter gets a branded acknowledgement email with their subject context.
• Failure handling: if the main send fails, the API returns an error instead of pretending the submission succeeded.

How web forms fit the broader lead-ops model

Web forms matter in OrcaPulse because they complement the social-channel capture system. The wider product already talks about one unified pipeline for CRM, CSV, LinkedIn, and website form demand, and the operator surfaces like Review Leads and Lead Hub are the places where richer lead handling can converge once capture flows are normalized.

In other words, the current contact-form route is the direct-site entry point, while the rest of the lead-operations stack defines where deeper qualification, routing, and review can happen as the form path evolves further.

• Direct site capture: web forms are the non-social front door for inbound intent.
• Operational fit: Review Leads and Lead Hub remain the natural places for downstream handling once form capture becomes more deeply normalized.
• Unified pipeline direction: the product positioning already treats website forms as part of the same inbound operating layer as social channels.

How to use web forms in the current project

Right now, the best way to think about web forms is as a reliable direct-contact channel with basic intake quality controls and immediate email-based handling. It is already real, but it is not yet a fully workflow-native capture engine in the same way the richer social paths are.

If you want to deepen this route next, the most valuable improvement would be converting accepted website form submissions into first-class lead records automatically so they move into the same qualification, routing, and follow-up flow as the rest of the system.

Next steps

After Web Forms, the next useful docs area is usually Integrations, starting with CRM Sync or Webhook Events, because those pages explain where captured demand goes next.