Angular contact form with Reactive Forms & HttpClient

Build a FormGroup with FormBuilder, then on (ngSubmit) append each control's value (plus access_key) to a FormData and call httpClient.post('https://splitforms.com/api/submit', fd).subscribe(…). Inspect data.success in next; handle 4xx in error.

Reactive Forms (FormBuilder, formControlName). They're synchronous, fully typed, unit-testable, and scale to cross-field validators. Template-driven forms with ngModel work for tiny forms but get unwieldy and harder to test. splitforms is form-agnostic — it only cares about the multipart body.

HttpClient routes any non-2xx response to the error callback of .subscribe({ next, error }) (or to catchError in the pipe). Inspect err.error?.message for splitforms' user-facing message. 2xx responses with success: false (e.g. spam flagged) still arrive in next — always check data.success there too.

Yes. The component above is standalone (standalone: true, imports ReactiveFormsModule). No NgModule changes. If you're on a NgModule-based app, just declare the component and provide HttpClient once via provideHttpClient() (or import HttpClientModule) in your app config.

You can't fully — Angular compiles to client-side JavaScript, so anything the component reads ends up in the bundle. The right mitigation is domain-locking the key in the splitforms dashboard (Settings → Allowed domains). For true server-side secrecy, proxy through an Angular Universal server route that injects the key from process.env server-side.

Yes, but POST from the browser, not during server rendering. Guard the HttpClient call with isPlatformBrowser(platformId) or keep it inside the (ngSubmit) handler (which only fires client-side). The form markup can render on the server; the submission must originate from the browser.

Angular's HttpClient inspects the body argument: pass a FormData instance and it sets Content-Type: multipart/form-data; boundary=… automatically. If you manually add a Content-Type: multipart/form-data header in the options (a common copy-paste from older AngularJS tutorials), Angular doesn't know the boundary string and the request body can't be parsed — splitforms returns 400 malformed body. Same rule as fetch and jQuery: leave the header alone when the body is FormData.

Unlike fetch, Angular's HttpClient treats any non-2xx status as an error and routes it to the error callback of .subscribe({ next, error }) (or to catchError in the pipe). That means splitforms' 4xx responses (invalid key, spam flagged, rate-limit) hit error, NOT next — so data.success is never checked for those cases and you'll miss the user-facing message entirely. Read err.error?.message in the error handler, or normalize both paths with catchError. Remember: 2xx with success: false still lands in next, so check data.success there too.

Bootstrap-style 'show errors after submit' isn't automatic in Angular — a control's errors are present in form.controls.email.invalid but the *ngIf template guard usually checks .touched too, so nothing displays until the user blurs the field. In submit(), call this.form.markAllAsTouched() before returning early on this.form.invalid, or users click Send on an empty form and see nothing happen. Also prefer the strict this.fb.group over fb.group (pre-14) which returned FormGroup<any> and let typos like form.controls.emial compile.