WEBVTT 00:00:01.000 --> 00:00:04.610 This accompanies our article on API integration. 00:00:05.000 --> 00:00:09.450 What if a system resends a message after the first order was created? 00:00:09.720 --> 00:00:14.250 A fictional approved CRM request goes to an administration system. 00:00:14.440 --> 00:00:16.170 Its message arrives twice. 00:00:16.600 --> 00:00:20.650 Without a stable reference, two draft orders could represent exactly 00:00:20.680 --> 00:00:22.010 the same request. 00:00:22.280 --> 00:00:26.170 Assign an immutable source reference and store it in the destination. 00:00:26.760 --> 00:00:29.930 A mapping table connects the customer reference with the correct 00:00:29.960 --> 00:00:33.210 existing customer number in the administration system. 00:00:33.480 --> 00:00:35.970 Only approved requests proceed. 00:00:36.280 --> 00:00:40.010 Validate required text, customer mapping and date format. 00:00:40.520 --> 00:00:44.490 A missing match or invalid date stops processing and receives an 00:00:44.720 --> 00:00:46.850 explicit error reason for follow-up. 00:00:47.160 --> 00:00:50.650 Searching first does not prevent duplicates when messages run 00:00:50.680 --> 00:00:51.650 concurrently. 00:00:51.880 --> 00:00:56.250 The destination must enforce a unique external reference even when two 00:00:56.280 --> 00:00:59.090 processing attempts start at the same time. 00:00:59.400 --> 00:01:01.850 After a timeout, the order may exist. 00:01:02.360 --> 00:01:05.130 Check the destination using that reference first. 00:01:05.560 --> 00:01:09.735 If the outcome remains unknown, request human review before attempting 00:01:09.760 --> 00:01:11.050 to create another order. 00:01:11.720 --> 00:01:15.530 Record source reference, processing status and error reason. 00:01:16.040 --> 00:01:19.850 An administrator needs to identify completed work and outstanding 00:01:19.880 --> 00:01:24.090 exceptions without blindly repeating the whole integration from the beginning. 00:01:24.680 --> 00:01:28.970 Test repeated and concurrent messages, missing fields and uncertain 00:01:29.000 --> 00:01:29.930 outcomes. 00:01:30.200 --> 00:01:34.375 Check current source status too: an old message must not reverse 00:01:34.400 --> 00:01:36.490 a newer state in the destination. 00:01:36.760 --> 00:01:40.770 A dependable integration needs more than a successful transfer. 00:01:41.080 --> 00:01:45.850 Our source article on API integration explains data agreements, error 00:01:45.880 --> 00:01:49.850 responses and controlled reprocessing in greater detail.